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ABS TBACT 


Until  recently,  much  of  the  budget  planning  for  software 
systems  has  been  primarily  targeted  at  costs  incurred  during 
the  development  phase.  However,  with  increasing  software 
system  life  span  and  complexity,  maintenance  costs  have 
become  a  more  prevalent  concern.  As  a  result  of  necessary 
corrections  for  design  errors  and  evolutionary  maintenance, 
post-delivery  investment  in  software  systems  now  reguires  a 
greater  proportional  share  of  the  life-cycle  costs.  In  this 
research,  various  methodologies  and  system  factors  relating 
to  software  cost  accounting  are  reviewed  with  the  intent  of 
developing  a  cost  control  model  for  arriving  at  a 
well-structured  view  for  the  management  of  the  maintenance 
phase  of  the  software  life-cycle.  The  model  proposed 
embodies  a  planning  concept  for  establishing  a  maintenance 
strategy  and  a  control  concept  for  analyzing  manloading 
requirements  during  the  maintenance  phase. 
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I.  INTRODUCTION 


A.  THE  PROBLEM 

Recent  literature  is  replete  with  dire  predictions  about 
the  ultimate  costs  of  software  maintenance.  In  1973,  costs 
of  software  in  the  United  States  were  $20  billion  [1]  and 
they  are  projected  to  be  $200  billion  in  1985  [ 2  ].  It  nas 
been  hypothesized  that  anywhere  from  fcrty  tc  ninety-five 
percent  of  the  manpower  effort  in  typical  industrial  appli¬ 
cations  occurs  during  the  maintenance  phase  cf  the  software 
life  cycle.  [3,  4,  5,  6,  7,  8,  9,  10,  11,  12,  13,  14] 

Although  there  are  numerous  models  in  existence  that 
deal  with  software  costs,  none  deal  specifically  with  the 
costs  of  'pure'  maintenance  during  the  latter  pnase  of  the 
software  life-cycle.  It  appears  that  much  of  the  Federal 
government  and  industry  tend  to  use  a  general  definition  of 
software  maintenance  and  treat  it  as  a  level  of  effort  on 
various  tasks  rather  than  that  effort  allocated  to  specific 
tasks.  Consequently,  these  organizations  do  not  really 
know  the  true  costs  cf  their  software  maintenance. 

The  goal  of  this  work  is  to  investigate  the  methodology 
of  software  cost  accounting,  and  to  evaluate  and  develop  a 
cost  model  for  the  prediction  of  pure  software  aaintenance 
costs. 
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The  term  'Software  Maintenance*  is  very  nebulous.  De¬ 


partment  of  Defense  Directive  5000.29  alludes  to  software 


maintenance  by  stating: 

"Correctness  of  software,  reliability,  integrity,  main¬ 
tainability,  ease  of  modification,  and  transferability 
will  be  major  considerations  in  the  initial  design." 
[15] 


Used  in  this  thesis  is  a  composite  definition  of  software 


maintenance  to  encompass  those  actions  taken  by  a  system 


user  to  retain  an  existing  system  m,  or  restore  it  to,  an 


operable  condition.  This  includes: 


1)  corrections  to  counteract  detected  hugs; 


2)  enhancements  to  add  functions; 

3)  modifications  to  delete  or  change  existing  functions  in 
tneir  nature  or  scope; 

4)  implementation  strategy  to  match  changed  conditions  or 
requirements.  [16,  iv,  18,  19,  20,  21,  22,  23,  24  ] 

•Pure*  Maintenance  on  the  other  hand  is  restricted  to 


that  work  accomplished  during  the  maintenance  phase  of  the 


software  life  cycle  in  the  pursuit  of  the  following  goals: 


1)  Helialibility  of  Software  -  the  ability  of  the  software 
to  produce  consistent  results  whenever  the  customer 
uses  the  product; 


2)  Error  Correction  -  changes  made  tc  counteract  errors. 
The  priority  of  correction  is  directly  related  to  the 
seriousness  of  the  error; 


3)  Software  Maintainability  -  extending  the  useful  life  of 
a  program  fcy  untangling  a  messy  one,  generalizing  a 
specific  one,  cr  annotating  an  unreadable  one. 


Robert  Glass  [25]  defines  the  best  software  aaintenance 


as  no  aaintenance  at  all.  That  is,  no  changes  are  needed  be¬ 


cause  no  errors  were  committed  and  all  changes  were  antici¬ 


pated.  He  then  goes  on  to  list  six  attributes  of  software 


aaintenance : 


1)  Maintenance  is  intellectually  very  difficult.  Problems 
cannot  be  bounded.  The  cause  could  be  anywhere. 

2)  Maintenance  is  technically  very  difficult.  Problems 
cannot  be  specialized.  They  could  surface  because  of 
errors  in  the  coding,  design,  architecture,  cr  concept. 


3)  Maintenance  is  unfair.  Usually  the  person  who  is  main¬ 
taining  a  product  did  not  write  it  and  must  interpret 
what  the  original  author  meant.  Documentation  is  in¬ 
adequate  most  of  the  time. 


4)  Maintenance  is  nc-win.  People  only  come  to  maintenance 
with  problems. 


5)  Maintenance  is  infamous.  There  is  very  little  glory, 
noticeaole  progress,  cr  chance  for  'success'. 


6)  Maintenance  lives  in  the  past.  The  general  quality  of 
coda  being  maintained  is  often  terrible.  This  is  part¬ 
ly  because  it  was  created  when  everybody's  understand¬ 
ing  of  software  was  mere  rudimentary,  and  partly  be¬ 
cause  a  great  deal  of  code  is  produced  by  people  before 
they  become  really  good  at  programming. 


Researchers  dc  not  appear  to  be  using  the  same  defini¬ 


tion  when  working  on  the  costs  of  maintenance.  Those  who  es¬ 


timate  maintenance  costs  to  be  near  forty  percent  of  life¬ 


cycle  costs  seem  to  be  using  a  definition  closer  to  that  of 


'pure'  aaintenance  while  those  who  estimate  aaintenance  as 


high  as  nir.ety-five  percent  are  obviously  using  a  very 
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general  definition.  According  to  recent  surveys,  most 
(seventy  to  eighty-eight  percent)  maintenance  effort  is 
spent  modifying  software  to  accomodate  changes  and  to  im¬ 
prove  software  performance  rather  than  to  correct  errors 
which  were  not  discovered  during  systems  development.  [26, 
27,  28]  These  surveys  have  been  substantiated  by  analyses 

done  on  three  large  scale  systems: 

1)  Pacific  Telephone  -  Service  Order  Retrieval  and  Distri¬ 
bution  System; 

2)  Bell  Telephone  Laboratories  -  Automated  Repair  Service 
Bureau  System; 

3)  VISA,  Inc.  -  Base  II  World  Wide  Credit  Card  Transaction 
Interchange  System.  £29] 

Although  hardware  costs  have  decreased  by  over  two 
orders  of  magnitude  and  programmer  productivity  has  in¬ 
creased  by  one  order  of  magnitude  in  the  last  ten  years,  the 
total  costs  of  systems  are  continuing  to  rise  with  the 
greatest  portion  of  effort  and  cost  spent  after  development 
completion  [30].  There  appear  to  oe  four  primary  reasons 
for  this  phenomenon: 

1)  Maintenance  is  people  intensive; 

2)  The  number  cf  systems  has  increased  substantially; 

3)  The  mission  of  the  software  seems  to  be  expanding; 

4)  Average  system  life  has  increased  from  three  years  in 
1960  to  rive  years  in  1970  to  eight  years  in  1980. 
[31,  32] 


A  recent  DOD  study  reports  that  development  costs  for 
Air  Force  avionics  software  averaged  $75  per  instruction 
while  maintenance  costs  lie  in  the  range  of  $4,000  per  in¬ 
struction  [33]  This  indicates  that  ninety-eight  percent  of 
the  life-cycle  costs  of  that  system  are  spent  cn  software 
maintenance.  Another  study  concludes  that  fifty  percent  of 
the  costs  for  Navy  Airborne  Antisubmarine  warfare  Tactical 
Software  is  spent  on  maintenance  software  [34].  As  one  can 
see,  there  are  many  different  meanings  of  the  term  'software 
maintenance'  and  as  many  different  assessments  of  its  cost. 

The  software  industry  does  not  appear  to  be  unified  in 
its  approach  to  decreasing  t-he  high  cost  of  maintenance. 
McClure  states: 

"A  solution  that  focuses  upon  the  production  phases  of  the 
software  life  cycle  does  not  address  the  major  portion  of 
the  maintenance  effort...  We  must  directly  address 
maintenance  issues  rather  than  hope  that  they  will  disap¬ 
pear  by  improving  the  development  process."  [35] 

Most  of  the  literature  expounds  the  theory  that,  to  be  done 
properly,  software  maintenance  should  be  a  conscious  goal 
from  the  beginning  of  the  software  development  process. 
Maintenance  is  all  too  often  left  out  of  planning  considera¬ 
tions  and  then  treated  as  a  helter-skelter,  uncoordinated 
activity  rather  than  a  planned,  methodical,  controlled  nec¬ 
essary  business  function  [36],  Long  term  planning,  just  as 
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in  ether  disciplines,  includes  the  provision  of  appropriate 
tools.  There  are  two  major  categories  cf  tools  for  mainte¬ 
nance.  Technical  tools  encompass  such  things  as  compilers, 
traps  and  traces,  dumps,  comparators,  editors,  reformatters, 
and  preprocessors.  Administrative  tools  include  problem  re¬ 
porting  vehicles,  status  reporting  vehicles,  and  documenta¬ 


tion  systems.  [37,  38,  39] 


Even  with  the  Knowledge  and  use  of  these  tools, 
tivity,  which  is  typically  measured  in  software 
code  (SLOC)  is  substantially  lower  for  maintenance 
mers  than  fer  development  programmers.  According 
maintenance  productivity  can  be  as  low  as  twenty  pe 


prod uc- 
lines  of 
program- 
to  Daly, 
rcent  of 


development  productivity  [40].  There  appear  to  oe  three 
main  reasons  fer  this  phenomenon: 


1}  There  is  a  stigma  attached  to  the  job  of  software 
maintenance.  Management  rarely  rewards  goed  work  in 
doing  maintenance  as  generously  as  good  work  in  doing 
development,  Both  coworkers  and  management  personnel 
act  as  though  they  held  maintenance  work  in  low  esteem. 
To  survive,  every  person  must  have  self  respect.  If  a 
job  is  not  perceived  as  important,  a  person  probably 
will  not  perform  to  the  best  of  his  abilities. 


2)  Usually,  maintenance  personnel  are  not  intimately  fa¬ 
miliar  with  the  cede  that  they  are  assigned  to  main¬ 
tain.  Typically,  a  maintain er  is  assigned  resoonsioil- 
itv  for  30,000  SLOC  [41].  Eecause  documentation  is 
guite  often  poor,  the  aaintainer  must  study  the  code 
itself  and  try  to  understand  what  the  original  develop¬ 
er  created  and  why  he  implemented  iz  in  that  manner. 
Osually  he  must  study  a  great  deal  more  code  than  the 
affected  area  to  avoid  inducing  bugs  in  a  seemingly  un¬ 
related  area  by  the  fix  that  is  implemented. 


3)  The  wrong  grade  of  people  are  v/oicaliy  used  to  staff 
maintenance  efforts  [42,  43,  44,  45,  46,  47,  4dt  49] 

Traditionally,  maintenance  efforts  are  aeinc  starred  oy 
less  experienced  personnel  than  develcomeht  projects. 


17 


However,  aaintenance  personel  should  be  senior  people 
because  software  aaintenance  is  a  microcosm  of  the  en¬ 
tire  software  development  process.  The  maintainer  does 
a  systems  analysis  of  a  problem  area  leading  to  a  re¬ 
quirements  definition.  Donning  a  designer's  hat.  tne 
aaintenance  person  then  outlines  the  inpact  or  the 
change  on  the  product.  Being  a  flexible  individual, 
the  haintainer  now  codes  the  design  solution.  After 
the  results  of  these  efforts  have  been  tested  and  veri¬ 
fied.  the  revised  product  is  finally  released  to  the 
world.  The  aaintenance  person  also  plays  a  liaison 
role  with  the  custoaer  by  explaining  anomalous  outputs, 
negotiating  changes  that  are  needed  as  opposed  to  those 
that  are  desired,  and  interpreting  tne  computer's 
unique  constraints.  As  you  can  see,  the  person  who 
maintains  a  complex  system  should  be  a  highly  talented 
and  motivated  individual.  [  50,  51  ,  52  ] 


C.  RESEARCH  MET  HCDOLCG Y 
1 •  Literature  Search 

Manual  searches  and  automated  system  searches  of  the 
literature  showed  little  had  been  published  in  this  field. 
Although  there  is  a  lack  of  published  material  that  deals 


directly  with  a  fiscal  approach  to  planning  and  control  of 


software  aaintenance,  the  researchers  found  a  great  deal 
that  was  very  useful  as  background  information  and  which 
helped  to  develop  the  theory  for  the  planning  and  control 
model . 

2.  Telephone  Ceave rsations 

Efforts  to  uncover  informal  sources  that  deal  spe¬ 
cifically  with  tbs  costs  of  'pure  maintenance'  failed.  The 
following  organizations  were  contacted  in  the  course  of  the 
research,  with  no  significant  results: 

Army  Computer  Systems  Command,  Ft.  Belvoir,  Va.; 

DOD  Computer  Institute,  Washington,  D.C.; 
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FEDSIM,  Washington,  O.C.; 

Homestead  Software  Support  Facility,  Homestead,  FI.; 

IBM  Federal  systems  Division,  Gatherstourg,  Md.; 

Kapur  Associates,  Danville,  Ca.; 

National  Security  Agency,  T3Q3,  Ft.  Meade,  Md. ; 

Naval  Security  Group  Activity,  Skaggs  Island,  Ca.  ;  and 

NARDAC  San  Francisco,  Alameda,  Ca. 

Maintenance  tracking  data,  dealing  with  Goddard 
Space  Flight  Center  projects,  was  ootained  from  the  Data  and 
Analysis  Center  for  Software,  Griffis  AFB,  NY.  Unfortunate¬ 
ly,  the  late  arrival  of  the  data  and  format  incompatibility 
precluded  inclusion  of  this  data. 

Unpublished  documents  describing  a  matrix  management 
method  of  functional  area  analysis  developed  by  Mr.  Kyle 
Rone,  IBM  Federal  systems  Division,  Houston,  Tx.  were 
obtained  and  significantly  contributed  to  the  formulation  of 
the  final  model. 

D.  ORGANIZATION  OF  THE  THESIS 

In  this  introduction  the  problem  has  been  stated,  rts 
importance  discussed,  and  it  has  been  placed  in  the  context 
of  the  overall  computer  system  development  process,  chapter 
two  covers  various  aspects  of  the  problems  encountered  when 
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estimating/deteraining  the  cost  or  software  maintenance. 
This  specific  background  material  is  needed  to  understand 
the  models  that  will  be  presented  in  chapters  three  and 
four.  Chapter  three  thoroughly  discusses  existing  models  in 
two  areas:  those  that  work  with  Norden-Rayleigh  curves,  and 
those  that  encompass  complexity  metrics.  Chapter  four  gives 
the  authors'  model  which  is  based  on  bcth  macrc-estimating 
(total  system)  and  micro-estimating  (unit  composition)  tech¬ 
niques.  Finally,  chapter  five  summarizes  the  thesis  and 
puts  forth,  conclusions  and  recoimendat;i<ys* 
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II.  QUANTIFYING  SOFTWARE  MAINTENANCE 

A.  THE  SOFTWARE  PROBLEM 

Thera  are  twc  main  reasons  that  maintenance  has  become  a 
predominant  cost  in  software  systems.  First,  the  volume  of 
completed  systems  which  require  maintenance  dominates  the 
systems  under  development  as  more  and  mere  long-lived  large 
systems  are  completed  and  delivered.  Second,  software  sys¬ 
tems  require  a  considerably  greater  proportional  investment 
in  error  correction  and  evolutionary  maintenance  after  de¬ 
livery  than  other  engineering  products. 

Numerous  technological  advances  have  not  solved  software 
problems.  They  have  increased  the  demand  for  software,  and 
opened  up  opportunities  to  use  computers  in  new  applications 
which  place  increasingly  severe  demands  on  software  tech¬ 
nology.  Often  the  tendency  is  simply  to  ignore  these  proo- 
lems.  Because  these  problems  are  both  technical  and  mana¬ 
gerial  in  their  scope,  a  "systems  engineering"  solution  is 
needed. 

Online  hardware  operation  and  support  models,  where  the 
cost  of  spares,  maintenance  manhours,  material,  training, 
etc.,  can  be  estimated  based  on  some  physical  characteris¬ 
tics  of  the  system,  software  maintenance  effort  is  strictly 
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i  function  of  manhours  to  perform  the  necessary  action. 
Thus  far.  Maintenance  costs  for  software  seen  to  te  primari¬ 
ly  an  estimate  by  an  expert,  someone  familiar  with  the 
changes  to  be  made  to  a  prograa,  rather  than  putting  certain 
parameters  into  a  cost  estimating  relation  and  calculating 
annual  Maintenance  costs. 

Software  maintenance  costs  cannot  be  ascribed  to  one 
specific  agent  or  event  but  instead  to  the  combined  action 
of  many  factors.  By  reviewing  some  of  these,  the  complexity 
of  the  problem  can  be  better  understood.  In  this  research, 
an  attempt  is  made  tc  isolate  areas  that  can  be  estimated  by 
formulas  and  then  to  establish  the  mathematical  relation¬ 
ships.  As  such,  the  following  topics  will  be  discussed  as 
they  relate  to  the  maintenance  function: 

1)  Software  Life-cycle; 

2)  Life-cycle  Interrelationships; 

3)  Software  Evolution; 

4)  Productivity; 

5)  Complexity  Metrics;  and 

6)  Error  Prediction. 
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B.  THE  SOFTWARE  LIFE-CYCLE 

In  the  aid  1970's,  the  phrase  "software  life-cycle"  was 
coined  and  became  a  popular  aeans  for  conveying  the  basic 
concepts  of  a  software  system:  multiple  phases  and  extended 
life.  Many  representations  of  the  life-cycle  exist;  by  com¬ 
monly  accepted  practice,  the  software  life-cycle  consists  of 
the  development  phase  and  the  maintenance  phase  taken  col¬ 
lectively.  Depicted  in  Figure  2.1  is  a  composite  schematic 
showing  this  relationship. 

This  diagram  oversimplifies  the  importance  of  the 
maintenance  phase.  A  more  accurate  role  of  the  maintenance 
function  is  detailed  in  the  life  cycle  model  (figure  2.2) 
developed  by  Roms  Air  Development  Center  [53].  From  this 
view,  maintenance  performed  during  the  operation  and  support 
phase  is  seen  to  be  a  highly  interactive  process.  The  con¬ 
jecture  apparent  from  the  diagram  is  that  the  same  procedur¬ 
al  requirements  fcr  software  development  must  be  duplicated 
during  the  maintenance  phase. 

The  basis  of  applying  a  life-cycle  management  scheme  to 
software  is  to  direct  attention  to  all  phases  encompassed  by 
the  system  life-cycle  and  the  contribution  of  each  phase  to 
the  total  life-cycle  expenditures.  Familiarity  with  and 
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Operations  and  Maintenance  Phase 
Figure  2.1.  Software  Life-cycle  -  Composite  Schematic 


24 


understanding  of  the  life-cycle  can  help  managers  make  ef¬ 


fective  distribution  of  the  resources  for  a  software  system 
which  will  ultimately  effect,  the  maintainability  of  the 
software . 

The  life-cycle  curves,  more  recently  called  "Rayleigh'1 
curves,  were  orginally  formulated  by  Lord  Sayleign,  tne 
British  Nobel  Laureate.  Presently,  these  curves  are  used  to 
represent  resource  allocation  (manpower)  of  a  software  pro¬ 
ject.  Preliminary  research  in  this  area  was  directed  at  re¬ 
source  consumption  in  research  and  development  (R&D)  pro¬ 
jects.  In  a  series  of  studies  conducted  by  Peter  Norden 
[54]  of  IBM,  it  was  established  from  a  large  body  of  empiri¬ 
cal  evidence  that  large  R6D  projects  follow  a  life-cycle 
pattern  as  described  by  the  Rayleigh  (manpower)  equation: 

2 

-at 

y  *  =  2Kate  (2.  1) 

where 

y*  =  the  number  of  person-years  of  effort  expended 
per  year, 

K  =  the  total  number  of  person-years  required  over 
the  life-cycle, 

a  =  the  curve  shape  parameter, 
t  =  elapsed  time  in  years,  and 
e  =  exponential  function. 
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The  principle  of  the  curve  is  as  follows: 


Hesearcn  has 


indicated  that  there  are  regular  patterns  of  manpower  build¬ 
up  and  phase-out  in  complex  projects.  These  patterns  are 
made  up  of  a  snail  number  of  successive  phases  or  cycles  of 
work  thorouqhout  the  life  cf  the  project.  Norden  linked  the 
cycles  to  obtain  a  project  profile.  when  the  individual: 
cycles  are  added  together,  they  produce  the  profile  of  the 
entire  project  (figure  2.3). 


Figure  2.3.  Project  Profile 


Peak  aanloading  tine  (t  )  culminates  during  final  stages 

d 

of  development  and  implementation  (figure  2.4)  .  Based  upon 


uAfiwvttutfeofu/rm 


Figure  2.4.  Hanloading  Profile 


Norden’s  studies  {55],  cumulative  resource  allocation  up  to 
this  time  accounts  for  approximately  forty  percent  of  tae 
life-cycle.  Occuring  at  the  low  end  of  the  curve  is  the  op¬ 
eration  and  maintenance  phase  which  absorbs  tne  remaining 
sixty  percent  of  life-cycle  expenditures.  The  greater  por¬ 
tion  of  costs  associated  with  this  phase  are  attributed  to 
the  "maintenance  tail"  or  expected  life  of  the  software  pro- 
iuct.  Failure  repair,  however,  rs  just  a  small  part  of 
Dost-delivery  maintenance  activities.  Studies  [ 5o  ]  show 
that  coding  errors  account  for  only  thirty  percent  of  tne 
post-delivery  errors.  The  greater  share  (seventy  percent)  is 
occasioned  because  there  is  a  mistake  in  design  or  specifi¬ 
cation.  Although  the  code  performs  exactly  as  designed,  this 
ices  not  reflect  the  original  operational  desires. 
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Logically,  it  would  seen  thar  aaintenance  manpower 
requirements  would  decrease  over  time  due  to  growth  m  reli¬ 
ability.  In  other  words,  as  programming  and  design  errors, 

*1* 

which  are  commonly  called  "bugs”,  are  found  and  corrected, 
the  time  to  the  next  system  failure  should  increase  through¬ 
out  the  aaintenance  phase  of  the  life-cycle.  This  reliabil¬ 
ity  assumption,  however,  is  disputable.  Maintenance  action 
taken  in  response  to  error  cccurance  can  have  three  possible 
outcomes : 

1)  the  actual  error  is  corrected; 

2)  the  error  is  corrected,  but  the  fix  induces  a  new 
error ; 

3)  the  error  is  not  corrected,  and  the  program  remains 
non -operational. 

Heliability  growth,  then,  is  a  probabilistic  event  which  de¬ 
pends  heavily  on  the  skills  cf  the  maintenance  programmers. 
If  the  maintainers  are  competent,  reliability  should  grow. 

Another  controversial  assumption  is  growth  in  maintain¬ 
ability.  When  maintainability  is  viewed  as  the  time  re¬ 
quired  to  return  a  software  system  to  an  operating  status 
following  a  system  failure  and  maintainability  growth  is 
viewed  as  the  decrease  in  time  required  to  correct  an  error, 
then  an  obvious  conclusion  would  be  growth  in  maintainaoil- 
ity.  Several  factors,  however,  may  produce  an  opposing 
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conclusion,  i.s.  decaying  maintainability.  Patchwork  fixes, 
in  addition  to  introducing  new  errors,  nay  produce  module 
interface  problems  and  documentation  inefficiencies  will 
complicate  the  finding  of  other  errors.  Reduced  familiarity 
with  a  software  system,  stemming  from  frequent  personnel 
turnover,  can  be  an  inhibitor.  Documentation  and  software 
(programming)  standards  and  controls  may  not  be  enforced  on 
new  releases.  Error  identification  and  correction  may  be¬ 
come  further  entangled  when  configuration  control  is  lax. 
Again,  the  competence  of  the  maintainers  will  influence  the 
results. 

C.  LIFE-CYCLE  INTER RELATIONSHIPS 

The  management  process  for  the  maintenance  cf  software 
involves  decisions  in  establishing  control  of  changes  to  the 
software  and  in  providing  for  the  implementation  cf  improved 
functional  capability  throughout  the  life-cycle  of  the  soft¬ 
ware.  The  planning  to  acquire  and  implement  resources  for 
software  maintenance  must: 

1)  consider  the  entire  life  of  the  software,  and 

2)  begin  early  in  the  life  of  the  software  in  order  to 
reserve  funding  and  identify  sufficient  resources  for 
the  future. 
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Different  tine  spans  and  levels  of  effort  exist  for  the 
different  phases  cf  a  software  project.  The  failure  to  ob¬ 
tain  quantitative  relationships  of  a  precision  comparable 
to  those  available  for  estimating  the  costs  of  hardware  sys¬ 
tems  has  led  to  the  belief  that  interrelationships  exist 
among  life-cycle  phases.  That  is,  the  amount  of  resources 
used  in  early  phases  impacts  heavily  cn  the  resource  re¬ 
quirements  for  later  phases.  tJsing  an  approach  similiar  to 
basic  economic  production  theory,  Thibodeau  and  Dodson  [57] 
developed  a  mathematical  model  to  describe  the  complexity  of 
the  phase  interrelations.  This  relationship  is  given  in  the 
form: 

a  b 

Q  »  SK  L  (2.2) 

where 

Q  =  the  level  of  output, 

K  =  the  amount  of  capital  input, 

L  =  the  amount  of  labor,  and 

A,  a,  and  b  are  empirically  derived  constants. 
Graphically,  this  is  shown  ir.  figure  2.5. 

To  add  a  term  representing  technological  change  or  to 
account  for  different  classes  of  labor  or  capital,  the  num¬ 
ber  of  input  resources  can  be  expanded  to 


a  1  a2  b 
Q  =  AK  K  L 
1  2 
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(2.3) 


Figure  2.5.  Economic  Production  Carve 
In  order  to  indicate  trade-offs  between  life-cycle  phases, 

the  sane  general  formulation  can  be  used  and  expressed  as 

b  c  d  k 

P  *  aX  X  X  X  (2.4) 

d  c  t  a 

where 

P  =  software  production  resulting  from  the  applica¬ 
tion  of  the  resources, 

X  =  person-months  of  inputs, 

a,  b,  c,  d,  and  k  are  empirically  derived  con¬ 
stants,  and 

subscripts  d,  c,  t,  ra  represent  designing,  coding, 
testing,  and  maintenance  respectively. 

A  further  assertion  made  by  Thibodeau  and  Dodman  indi¬ 
cated  that  limitations  in  design  resources  (e.g.  a  reduction 
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in  planned  resources)  may  be  passed  through  the  development 
phases  with  final  impact  in  the  maintenance  phase  (higher 
error  rates) .  Based  on  the  mathematical  postulate  previous¬ 
ly  described,  this  type  of  relationship  can  be  shown  by  the 
graph  in  figure  2.6. 


Figure  2.6.  Application  of  Production  Theory 

In  describing  the  infinite  set  of  relationships,  table  I 
illustrates  some  departures  from  the  ideal  which  may  occur, 
and  how  a  reduction  or  increase  of  resources  in  these  phases 
will  be  reflected  in  the  error  rate  of  the  delivered  soft¬ 
ware.  While  it  can  be  argued  taat  the  ideal  error  rate  may 
be  zero,  a  more  practical  solution  would  be  to  avoid  de¬ 
dicating  an  enormous  amount  of  resources  to  achieve  zero 
errors.  As  a  result,  it  would  be  expected  that  for  most 
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information  systems,  planning  would  allow  for  some  marginal 
error  rata.  However,  this  tolerance  of  errors  does  not  nec¬ 
essarily  apply  to  tactical  defense  systems. 

D.  SOFTWARE  EVOLUTION 

Operational  software  systems  undergo  a  continuing  pro¬ 
cess  of  evolution,  the  phases  of  which  are  repair,  modifica¬ 
tion,  enchancement,  and  adaptation.  Continuing  evolution  is 
the  visible  sign  of  continuing  interaction  between  the  sys¬ 
tem  and  its  environment.  Even  if  — and  this  rarely,  if 
ever,  occurs —  its  first  implementation  was  perfectly  con¬ 
ceived,  perfectly  designed,  and  perfectly  implemented,  a 
program  will  require  general  maintenance. 

Evolution  dynamics  is  a  theory  describing  the  change  of 
a  software  system  over  a  period  of  time.  The  theory  distin¬ 
guishes  between  rrogressi ve  work  (to  introduce  new  features) 
and  antigr essive  work  (fault  correction,  testing  activity, 
and  investment  in  methodology  to  combat  the  complexity  which 
grows  with  system  size)  [53].  The  basic  assumption  of  pro¬ 
gramming  evolution  dynamics  is  that  it  is  legitimate  and 
necessary  to  view  a  large  program  and  its  maintenance  orga¬ 
nization  as  interacting  systems.  Thus  one  must  search  "for 
models  that  represent  laws  that  govern  the  dynamic  behavior 
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Hypothetical  Phase  Interrelationship  Trade-offs 


1 

Hypothetical  cases  | 


I  1  2 

Analysis  and  design  >  * 

Coding  and  checkout  *  < 

Testing  =  = 

Maintenance  =  - 

Changes  Ho  Ho 

Reported  error  rate  <  > 


3  4  5  6  7 

=  <  =  > 

<  =  *  >  < 

>  =  =  >  < 

*  a  a  *  > 


Ho 


No  Yes  Yes  Ho 

>  >  =  > 


Symbols: 

=  equal  to  ideal 
>  greater  than  ideal 
<  less  than  ideal 
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of  the  aetasystea  of  organization,  people,  and  program  ma¬ 
terial  invoked  in  the  creation  and  aaintenance  process'* 
[59,  60  ]. 

Feedback  is  basic  to  the  process  since  the  systea  and 
system  designers  are  considered  as  a  aetasysteo.  The  key  to 
good  feedback  is  in*  nsive  use  over  time.  The  more  the 
software  is  used,  the  better  it  gets,  as  long  as  deficien¬ 
cies  are  fed  back  into  the  aaintenance  group  and  corrections 
are  made.  This  statement  holds  true  provided  that  the  maia- 
tainers  introduce  fewer  errors  than  they  resolve.  Likewise, 
the  longer  it  is  used  the  less  the  probability  that  the  sys¬ 
tem  contains  major  deficiencies.  In  analyzing  a  software 
development  systea,  a  simple  beginning  would  be  as  shown  in 
figure  2.7.  'When  pressure  is  exerted  to  provide  bigger  re¬ 
leases  (later  versions  cf  a  system  that  contain  enhancements 
and/or  corrections) ,  the  results  are  aore  complexity,  re¬ 
duced  quality,  and  growth  rate  limiting  factors.  Eventual¬ 
ly,  releases  are  made  solely  for  restructuring/rewriting. 
At  this  point,  a  fission  effect  is  possible  where  excessive 
growth  leads  to  systea  breakup. 

Various  published  papers  [61,  62]  have  discussed  the 
characteristics  and  dynamics  of  the  evolution  of  large 
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Figure  2.7.  Development  Release  Cycle 

programs,  with  the  aost  significant  contribution  cf  research 
lone  by  Lehman  and  Belady  [63,  64],  Their  efforts  ware  di¬ 
rected  at  understanding  the  dynamics  of  the  software  life¬ 
cycle,  thereby  creating  an  enhanced  environment  of  manageri¬ 
al  awareness  and  an  understanding  of  system  behavior.  Long 
term  unpredictability  of  the  system  development  and  mainte¬ 
nance  processes  have  been  attributed  to  the  human  irterface. 
However,  it  has  been  found  that  measures  of  system  activity 
such  as  number  of  modules  handled,  inter-r elease  time,  and 
total  number  of  modules  in  the  system,  show  an  unusual 


37 


regularity.  Since  this  regularity  could  not  be  attributed 
to  management  decisions,  Lehman  and  Belady  have  tried  to 
analyze  it  through  the  use  of  evolution  dynamics.  3y  de¬ 
scribing  the  environment  of  program  creation  and  maintenance 
in  terms  of  regularities,  trends,  and  patterns,  taey  have 
proposed  laws  governing  the  evolution  dynamics  (taoie  II)  . 

Features  of  these  evolutionary  trends  were  further  sup¬ 
ported  in  a  more  recent  study  by  Leintz  knd  Swanson  [65]. 
Analysis  of  data  obtained  from  an  extensive  survey  indicated 
that  *he  magnitude  of  a  maintenance  effort  can  be  explained 
by  the  combined  efforts  of  four  variables:  system  age,  sys¬ 
tem  size,  relative  amount  of  routine  debugging,  and  the  re¬ 
lative  experience  of  the  maintainers.  The  relationships  of 
these  variables  were  modeled  as  shown  in  figure  2.8.  Amount 
of  maintenance  effort,  the  dependent  variable,  is  seen  to  be 
influenced  through  five  other  causal  paths  involving  four 
variables.  Each  causal  path  is  initiated  from  the  indepen¬ 
dent  variable,  system  age. 

S.  PRODUCTIVITY 

Productivity  is  often  considered  a  measure  of  the  trans¬ 
formation  of  meaningful  and  controllable  units  of  input  to 
meaningful  and  controllable  units  of  output.  The  question  of 
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TABLE  II 


Laws  of  Evolution  Dynamics 


CONTINUING  CHANGE 

A  oroqram  that  is  used  and  that,  as  an  implementation 
of  its  soecif icat ion ,  reflects  seme  ctner  reality, 
underaoes  continuing  change  or  becomes  progressivexy 
less  useful.  The  change  or  decay  process  continues 
until  it  is  judged  more  cost  effective  to  replace  the 
program  with  a  recreated  version. 


INCREASING  COMPLEXITY 

As  an  evolving  program  is  continuously  changed,  its 
complexity,  reflecting  deteriorating  sturcture,  in¬ 
creases  unless  werk  is  done  to  maintain  or  reduce  it. 


THE  FUNDAMENTAL  LAB 

(OF  PROGRAM  EVOLUTION) 

Program  evolution  is  subject  to  a  dynamics  wnich 
makes  the  programming  process,  and  hence  measures  of 
global  project  and  system  attributes,  self-regulating 
with  statistically  determinable  trends/in  variances. 


CONSERVATION  OF  ORGANIZATION  STABILITY 
(INVARIANT  iiCRK  RATED) 

The  global  activity  rate  in  a  project  supporting  an 
evolving  program  is  statistically  invariant. 


CONSERVATION  OF  FAHILIARITI 
(PERCEIVED  COMPLEXITY) 

The  release  content  (changes*  additions,  deletions) 
of  the  successive  releases  or  an  evolving  program  is 
statistically  invariant. 


quality  must  be  understood  in  all 
if  they  are  to  have  meaning.  It 
productive  when  producing  throwawa 
producing  high  quality  output. 


measures  of  productivity, 
is  far  easier  to  De  mere 
y  products  than  it  is  when 
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Figure  2.8.  Casual  Paths  of  Maintenance  Effort 

If  software  is  sized  in  terns  of  a  product  measure  such 
as  the  number  of  instructions  or  nodules,  then  the  assumed 
personnel  productivity  against  those  measures  is  a  key  vari¬ 
ant  in  the  estimate.  Since  producing  software  is  a  very 
labor  intensive  activity,  consuming  greater  than  eighty  five 
percent  of  the  resources  allocated  for  software  deveiopment 
f 66  ],  an  essential  ingredient  for  arriving  at  an  accurate 
cost  estimate  cf  the  software  lies  in  personnel  productivi¬ 
ty.  Generation  cf  software  is  creative  and,  therefore,  a 
wide  variance  across  personnel  productivity  can  be  expected. 
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3udget  9sti.aati.cns  required  fcr  software  development 
have  led  to  an  abundance  of  research  exploring  the  topic  of 
programming  productivity  £  67,  68,  69  ]  Traditional  measures 

of  software  productivity  have  included: 

1)  dollars  per  defect, 

2)  lines  of  code  (LOC)  per  person-month  (PM), 

3)  dollars  per  LCC, 

a)  dollars  per  PM,  and 

5)  complexity  branch  per  1000  LOC. 

Maintenance  researchers  pose  the  yet  unanswered  ques¬ 
tion:  Can  the  same  criteria  be  applied  for  productivity 

during  the  maintenance  phase?  Within  a  maintenance  scenar¬ 
io,  module  constituents  of  a  software  application  can  be 
categorized  as  new,  modified,  retained,  and  converted  (fig¬ 
ure  2.9).  New  segments  consist  of  entirely  new  code.  Modi¬ 
fied  segments  are  composed  of  changed  code  and  the  unchanged 
code  that  may  be  affected  by  the  changed  code.  Retained 
code  consists  of  previously  developed  and  tested  segments 
that  will  be  integrated  into  the  software  products  without 
being  modified.  Converted  code  is  existing  code  converted 
to  another  language.  Each  of  the  categories  of  code,  wnen 
related  to  a  specific  product,  may  produce  a  unique  produc¬ 
tivity  rate. 
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Pigure  2.9.  Categories  of  Program  code 


Factors  which  influence  productivity  have  been  widely 
researched.  Data  collected  from  sixty  projects  by  Balstoa 
and  Felix  showed  that  significant  relationships  existed 
between  productivity  (SLOC)  and  the  ratio  of  developed  code 
to  the  sum  of  original  (or  reused)  code  plus  the  developed 
code  [70].  The  resulting  plot  shown  in  figure  2.10  suggests 
that  productivity  is  highest  when  there  is  no  original  or 
reused  code,  that  is,  when  all  the  code  is  developed  from 
the  inception  of  the  project.  As  the  percentage  of  reused 
code  grows,  the  expected  productivity  decreases. 
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Ratio  of  Developed  tc  Original  and  Developed  Code  (percent) 

Figure  2.10.  Productivity  -  Reused  Code  Relationship 

Recent  investigations  done  by  Swanson  and  Leintz,  re¬ 
vealed  that  while  productivity  techniques  have  teen  exten¬ 
sively  discussed,  few  systemic  studies  of  benefits  in  tae 
maintenance  phase  have  been  conducted  [71].  Figure  2.11 
shows  some,  but  not  all,  cf  the  factors  commonly  cited  as 
indices  of  productivity. 

Maintenance  ccsts  oust  be  viewed  collectively  with  pro¬ 
ductivity.  To  dc  less  is  to  focus  on  only  part  cf  the 
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Figure  2.11.  Productivity  Determinants 

issue.  It  could  be  a  misleading  focus  if  management  dic¬ 
tates  policies  that  result  in  high  productivity  during  de¬ 
velopment  work  tut  adversely  affect  the  productivity  of 
post-delivery  maintenance.  If  the  productivity  is  negative¬ 
ly  affected  because  of  internal  problems  prior  to  delivery 
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or  reduced  quality  when  in  use,  then  costs  will  increase  and 
affect  the  potential  to  complete  other  projects. 


F.  COMPLEXITY  METBICS 

Quantitative  metrics  which  assess  the  complexity  of 
software  continue  to  attract  a  high  degree  of  interest. 
These  metrics  are  assumed  to  be  valuable  aids  in  determining 
the  quality  cf  software.  A  collection  of  such  metrics  which 
assess  numerous  factors  that  constitute  this  nebulous  “soft¬ 
ware  quality"  have  been  proposed  £72,  73],  Such  factors  in¬ 
clude  reliability,  portability,  maintainability,  and  myriad 
other  xxx-abilities. 


Potential  uses  for  measures  which 
factors  are  manifold.  Importance  of 


assess  these  various 
metric  relationships 


lias  in  the  following  areas: 


1)  As  feedback  to  programmers,  they  cat  be  used  dunna  de- 
veloDment  to  indicate  potential  problems  with  developed 
code*  [74].  A  design  is  evaluated  with  the  metric  rela¬ 
tionships  in  mind.  If  it  appears  that  this  design  falls 
outside  of  the  metric  bounds,  then  another  design  must 
be  contemplated. 


2)  In  guiding  software  testing,  McCabe's  cyclomatic  number 
has  been  proposed  as  a  means  of  assessing  the  computa¬ 
tional  complexity  of  the  software  testing  problem  [75]. 
Other  metrics  which  index  the  quality  cr  complexity  of 
software  may  help  identify  modules  or  subroutines  wnich 
are  likely  to  be  most  error-infested. 


3)  If  one  of  a  combination  of  metrics  can  be  empirically 
related  to  the  difficulty  programmers  experience,  then 
more  accurate  estimation  can  be  made  or  the  manpower 
that  will  be  necessary  during  maintenance. 
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In  using  these  metrics,  it  is  important  to  distinguish 
between  the  computational  and  psychological  complexity  of 
software,  since  reasons  for  assessing  them  differ  Computa¬ 
tions  1  complexity  refers  to  "the  guantitative  aspects  of  the 
solutions  to  computational  problems"  [76]  such  as  comparing 
the  efficiency  of  alternate  algorithmic  solutions.  To  il¬ 
lustrate,  as  the  number  of  distinct  control  paths  tnrough  a 
program  increases,  the  computational  complexity  may  in¬ 
crease.  Psychological  complexity  refers  to  characteristics 
of  software  which  make  it  difficult  to  understand  and  work, 
with.  Psychological  complexity  can  then  be  thought  of  as 
assessing  human  performance  on  programming  tasks.  Subse¬ 
quent  sections  will  discuss  currently  used  metrics  that  aare 
been  coupled  with  the  maintenance  effort  in  an  attempt  to 
predict  programmer  effort  required  to  complete  a  specific 
maintenance  task. 

1 •  Halstead  1 s  S 

During  the  last  few  years  research  aimed  at  the  de¬ 
velopment  of  a  "software  science"  has  supported  the  conten¬ 
tion  that  there  may  be  simple  theoretical  explanation  for 
the  structural  characteristics  of  many  computer  programs  ana 
that  there  is  a  strong  guantitative  relationship  between 
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these  characteristics  and  the  effort  required  tc  write  pro- 
grans  [77,  78,  79  ].  Based  on  the  theory  cf  software  sci¬ 
ence,  five  entities  of  an  algorithn  expressed  in  a  language 
are  measur eable : 

*  number  of  distinct  operators, 

n  =  number  of  distinct  operands, 

2 

N  =  total  number  of  operators, 

1 

N  =  total  number  of  operands,  and 
2 

* 

=  number  cf  input/output  parameters  for  the 
algorithm . 

From  these  measurements,  some  defined  properties  for  pro¬ 
grams  can  be  calculated:  length  (N) ,  vocabulary  (n) ,  voiume 
(V)  ,  and  program  level  (L)  .  [80] 

Using  the  simple  relationships  between  these  metrics 
and  the  effort  (i)  required  by  a  programmer,  Halstead  ar¬ 
rived  at  an  expression  of  effort  (total  number  of  elementary 
mental  discriminations)  to  generate  a  given  program  where 


2  =  -  3 


n  N  ( N  +  N  )  log  (n  ♦  n  ) 
12  1  2  2  1  2 


(2.5) 


3y  applying  the  Stroud  number,  which  is  the  number 
of  eleaentry  pieces  of  data  that  a  person  can  mentally  sep¬ 
arate  per  second  (S) ,  a  dimension  of  time  is  introduced  to 
the  effort  equation: 
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(2.6) 


7 

S  SL 

where  T  indicates  the  estimated  time  fcr  programming.  Ex¬ 
cept  for  the  Stroud  number,  all  parameters  on  the  right  side 
of  the  equation  are  directly  measureabie  for  any  implementa¬ 
tion  cf  an  algorithm.  Research  methods  using  calculated  T 
values  have  shewn  that  a  strong  correlation  exists  with  the 
actual  time  measurements  in  the  absence  of  certain  ''impuri¬ 
ties''  which  correspond  to  common  undesirable  programming 
practices  such  as  unstructured  code,  low  module  cohesive¬ 
ness,  high  module  coupling,  etc.  [81]. 

2 .  McCabe ' s  v  (G) 

More  recently,  T.  McCabe  £82]  developed  a  complexity 
definition  based  on  the  decision  structure  of  a  program. 
McCabe's  metric  is  the  classical  graph  theory  cyclomatic 
number  v  (G)  defined  as: 

v  (G)  *  number  of  edges  -  number  of  nodes 

♦  2  (number  of  connected  components). 

Two  simpler  methods  cf  calculating  v(G)  are  presented  by 

McCabe:  the  number  of  predicate  nodes  plus  1  or  the  number 

of  regions  computed  from  a  planar  graph  of  the  control  flow. 

Literally,  this  complexity  metric  counts  control 
path  segments  which,  when  combined,  will  generate  every 
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possible  path  through  the  program.  Since  additional  control 
paths  could  make  a  program  more  difficult  to  understand,  the 
number  of  basic  paths  indexed  by  this  metric  may  also  relate 
to  mental  difficulty  of  a  programming  task. 

G.  ERROR  PREDICT  ION 

If  managers  knew  how  a  program  behaved  for  every  con¬ 
ceivable  combination  of  inputs  and  could  accurately  predict 
all  future  input  combinations,  then  they  would  knew  precise¬ 
ly  hew  many  errors  are  in  that  program  and  could  predict  at 
which  point  in  time  that  the  program  would  next  fail.  As  a 
result,  it  would  be  fairly  simple  to  program  resources  for 
software  maintenance.  The  only  real  decision,  then,  would  be 
whether  the  annoyance  from  the  error  was  worth  the  effort  to 
eliminate  it.  Because  this  ideal  situation  is  not  a  realis¬ 
tic  representation  of  the  world,  except  in  the  most  trivial 
programs,  it  would  ce  a  great  aid  to  managers  to  have  a 
method  to  predict  residual  errors  with  a  reasonable  degree 
of  certainty.  This  capability  would  arm  them  with  a  good 
guide  for  programming  the  amount  of  aaintsnar.ee  effort  need¬ 
ed  for  the  next  time  period. 

In  the  early  days  of  computing,  managers  obtained  rough 
estimates  of  the  number  of  errors  in  a  module  by  assuming 
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that  there  was  one  tug  in  every  sixty  lines  of  code  or 
perhaps  in  every  cne  hundred  lines  of  cede  depending  on  each 
aanager's  optimism  and  experience  £83].  It  seems  to  be  a 
reasonable  assumption  that  there  is  a  tetter  way  to  predict 
residual  errors.  The  importance  of  error  detection  analysis 
has  been  recognized  in  the  past  few  years  and  many  studies 
have  addressed  this  problem.  [84,  85,  86,  87,  8a,  89,  90, 
91]  An  important  objective  of  most  of  this  work:  has  oeen 
to  develop  analytical  techniques  to  examine  the  error  phe¬ 
nomenon  in  order  to  compute  or  predict  items  of  interest 
such  as  the  number  of  errors  detected  at  time  t,  the  pre¬ 
sumed  number  of  remaining  errors  at  time  t,  and  the  software 
reliability  function.  (It  should  be  noted  that  none  of 
these  studies  deals  specifically  with  the  detection  or  the 
prediction  of  errors  during  the  maintenance  phase  of  the 
software  life-cycle.) 

One  would  expect  software  reliability  to  improve  with 
age  because  latent  bugs  are  detected  and  are  presumably  cor¬ 
rected.  However,  there  are  exceptions  to  this  general  state¬ 
ment.  Bugs  can  be  induced  into  programs  while  corrections 
are  being  made.  This  situation,  called  the  ’’ripple  effect", 
generally  happens  in  very  large  systems  like  0/S360  instead 
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of  small  systems  like  a  compiler  [92],  When  a  change  is 
made  in  module  'A*  it  affects  the  way  module  'B'  works.  The 
maintainer  has  neither  the  desire  to  change  another  module 
nor,  probably,  any  idea  that  his  change  would  affect  another 
module.  With  vast,  complex  systems  it  is  impossible  for  any 
person  to  know  all  of  the  ramifications  of  a  change.  Since 
most  operational  software  is  subject  to  enhancements  and 
changes  in  requirements  because  of  the  dynamic  environment 
in  which  it  is  run,  it  can  be  expected  that  bugs  will  be  in¬ 
duced  with  the  new  code  and  that  other  modules  will  be  af¬ 
fected  through  interfaces  with  the  new  modules.  In  toe  long 
run  however,  it  appears  that  most  software  projects  follow 
the  predicted  process  and  have  fewer  errors  as  time  elapses 
[93].  Table  III  [94]  provides  data  to  support  this  phenome¬ 
non.  Observe  the  great  variability  of  tne  data  and  the  in¬ 
creased  reliability  as  time  passes. 

Although  the  code  appears  to  become  more  reliable  as 
time  passes,  there  are  still  problems  with  error  prediction 
models.  Many  of  these  models  assume  a  constant  error  rate 
[  95,  96,  97,  98,  99].  This  does  not  strike  one  as  being  a 
reasonable  assumption  on  three  accounts.  First,  the  failure 
rate  will  fluctuate  because  the  frequency  of  execution  of 
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Successive  Execution  Tines  Between  Failures 


(.leasured  in  seconds,  read  left  to  right  and  top  to  bottom.) 
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10 
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790 
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3321 

1045 
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5485 

1  160 
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the  areas  cf  cods  varies.  Some  areas  say  never  be  executed 
[100].  As  an  example,  if  one  assumes  that  there  are  one 
hundred  bugs  in  a  program,  that  the  failure  rate  is  fifty 
failures  a  week,  and  that  cue  is  using  a  constant  error  rate 
prediction,  then  after  fifty  bugs  have  been  eliminated  the 
failure  rate  should  be  to  be  twenty-five  failures  per  week. 
If  the  bugs  are  eliminated  in  the  order  that  they  are  de¬ 
tected,  the  first  fifty  to  be  eliminated  would  be  in  the 
most  frequently  exercised  areas  of  code  and  the  observed 
failure  rate  would  be  less  than  twenty-five  per  week.  If, 
on  the  other  hand,  the  most  severe  errors  were  corrected 
first,  there  may  be  a  situation  wnere  there  are  several  an- 

I 

noying  but  non-critical  bugs  in  a  highly  exercised  portion 
of  code  and  the  observed  failure  rate  is  forty  failures  per 
week  despite  having  eliminated  fifty  bugs. 

Second,  according  to  Ottenstein  [101],  the  error  rate 
for  modules,  at  the  validation  and  integration  stage,  varies 
inversly  with  the  size  of  a  module.  This  theory  has  been 
corroberated  by  Motley  and  Brooks  [102].  Motley  and  3rooks 
feel  that  this  inverse  proportion  is  an  indication  that 
the  larger  modules  were  not  as  fully  debugged  during  the 
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validation  and  integration  stages  and  would  go  into  the  op¬ 
erations  ar.d  maintenance  phases  with  a  greater  proportional 
amount  of  errors.  Ottenstein  explained  the  phenomenon  in 
lust  the  opposite  manner.  She  feels  that  there  is  a  learn¬ 
ing  and  retention  benefit  hat  operates  with  large  modules 
ar.d  thus  the  larger  modules  will  go  into  operations  and 
maintenance  with  a  smaller  proportional  amount  of  errors. 

A  third  reason  for  a  variable  rate  of  errors  at  the 
validation  and  integration  phase  is  also  proposed  by  Otten¬ 
stein  [103].  Earlier  developed  modules  are  more  fully  de¬ 
bugged  in  the  initial  testing  because  at  that  period  in  the 
project  there  is  a  lot  of  time  and  money  to  do  the  job  cor¬ 
rectly.  However,  modules  that  are  developed  near  the  end  of 
a  contract  appear  to  be  hastily  and  incompletely  debugged 
before  being  submitted  for  validation  because  both  time  and 
money  are  running  out.  The  authors  propose  a  corollary  to 
this  hypothesis.  The  more  over-budget  and  behina-schedule 
that  a  project  is  delivered,  the  higher  should  be  the  pre¬ 
diction  of  errors  detected  in  the  maintenance  phase. 

Sven  if  a  manager  could  accurately  predict  the  number  of 
errors  that  will  ce  detected  in  a  given  time  period,  there 
would  still  be  a  problem  in  scheduling  the  proper  amount  of 
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resources.  Different  types  of  errors  will  require  different 
amounts  of  effort  for  correction  because  they  are  of  differ¬ 
ent  complexities. 

H.  CHAPTER  SUMMARY 

Numerous  software  topics  are  under  study  in  an  attempt 
to  uncover  explanations  for  the  phenomenology  of  the  soft¬ 
ware  life-cycle.  Of  more  specific  concern  are  the  events 
which  lead  to  the  increased  expenditures  during  the  opera¬ 
tion  and  maintenance  phase  cf  the  software  project.  Indica¬ 
tions  from  research  evidence  are  that  net  one  single  factor 
can  be  named  as  the  dominant  contributor  to  the  life-cycle 
maintenance  costs.  Instead,  a  multiplicity  of  factors  are 
cited  as  having  an  impact  on  the  total  system. 

Recognizing  the  futility  of  identifying  a  single  con¬ 
tributor,  reseachers  have  resorted  to  finding  the  control 
elements  that  best  define  the  changes  that  occur  in  system 
characteristics.  With  a  continued  research  effort,  better 
understanding  and  increased  familiarity  of  these  system  con¬ 
trol  elements  may  lead  tc  positive  results  in  linking  sys¬ 
tem  characteristics  with  maintenance  requirements. 
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IIX.  COST  estimajjon  of  software  maintenance 


Coupling  the  rising  costs  of  computer  software  with  the 
relative  decline  in  computer  hardware  costs  would  indicate 
that  computer  software  acquisition  cost  and  maintenance  and 
operation  cost  (collectively  referred  tc  as  software  life- 
cycle  costs)  constitute  the  greatest  share  of  the  data  pro¬ 
cessing  budget.  Consequently,  predicting  future  software 
costs  for  both  existing  systems  (maintenance  and  operation 
costs)  and  new  development  is  of  increasing  concern  to 
management . 

The  phenomenology  of  the  software  development  and 
maintenance  prccess  is  not  definitively  known.  Research 
suggests  the  existence  of  a  fairly  clear  time-varying  pat¬ 
tern  such  as  a  Rayleigh  curve  or  seme  ether  similiar  form. 
The  analysis  is  complicated  by  the  presence  of  "noise"  or 
stochastic  components.  Additionally,  the  observable  compo¬ 
nents  (manpower,  cost,  time)  are  strongly  subjected  to  man¬ 
agement  perturbation.  This  would  indicate  that  although  a 
system  has  a  characteristic  life-cycle  behavior,  if  that  be¬ 
havior  is  not  known  to  managers  §  then  they  will 
respond  reactively  (non-optimally  with  time  lags)  to  system 
demands.  A  reasonable  basis  now  exists  for  expecting  that 


56 


an  adequate  phenomenological  description  nay  arise  from  the 
following  sources: 

1)  statistical  aechanics; 

2)  information  theory  coupled  with  statistical  communica¬ 
tion  theory; 

3)  diffusion  and  transport  theory.  [104] 

Tracking  of  casts  throughout  the  life-cycle  is  important 
because,  as  pointed  out  in  chapter  Two,  sixty  percent  of  the 
life-cycle  effort  is  consumed  during  the  operations  and 
maintenance  phase.  If  this  phase  is  treated  as  a  level-of- 
effort  task,  then  far  more  resources  than  necessary  for 
maintenance  are  used.  Given  a  fixed  manpower  or  budget 
constraint  (very  common  in  government) ,  less  than  optimal 
control  of  the  work  during  this  phase  increases  the  possi¬ 
bility  of  maintenance  work  saturation  (i.e.  devoting  all  re¬ 
sources  to  maintenance) .  This  situation  leaves  no  capability 
to  accomplish  additional  work. 

Within  the  scope  of  this  discussion,  three  types  of 
models  for  addressing  maintenance  cost  sstimc.icn  will  be 
considered: 

1)  software  cost  estimation  from  a  macr  oestiaatmg  view 
using  the  Ncrden-Rayleigh  curve  parameters; 

2)  software  cost  estimation  from  a  aicroest iaating  view 
using  a  work  breakdown  structure (WES)  methodology; 

3)  software  evolution  dynamics  using  system  complexity  as 
a  cost  monitor. 
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The  fonat  of  presentation  will  include  a  general  descrip¬ 
tion  of  the  model  with  subsequent  application  of  the  model 
to  the  forecasting  of  costs  within  a  maintenance  scenario. 

A.  SOFTWARE  COST  ESTIMATING  MODELS 

1 .  Putnam  *  s  Soft  ware  Cost  Estimating  Model 
a.  Description 

This  model  attempts  to  provide  quantitative  an¬ 
swers  to  the  questions  often  asked  by  managers  about  soft¬ 
ware  projects.  These  questions  are  generally  concerned  with 
project  time  duration,  total  cost,  and  the  accuracy  of  the 
figures  presented.  Putnam's  £105]  methods  provide  estimates 
in  the  following  areas: 

1)  Total  life  cycle  effort  in  manyears; 

2)  Cost  for  the  project; 

3)  Peak  manpower  needed; 

4)  Manpower  needed  at  any  specific  time  or  phase  in  the 
project; 

5)  Sisk  and  variance  analysis  of  derived  estimates;  and 

6}  Linear  programming  (LP)  techniques  to  impose  real  world 
management  constraints. 

Putnam's  contribution  tc  software  cost  estimat¬ 
ing  was  to  apply  the  Rayleigh  curve  to  software  life-cycle 
manloading.  Using  the  techniques  based  upon  the  life-cycle 
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theory  developed  by  Norden,  Putnam  did  a  number  of  empiri¬ 
cal  studies  and  found  that  the  software  life-cycle  exhibits 
a  rise  in  manpower  up  to  a  peak  and  then  a  trailing  off. 

Basically,  the  Putnam  model  obtains  estimates  of 
the  measure  of  work  in  man-years  and  of  the  total  develop¬ 
ment  time  of  the  project.  Development  time  in  the  Putnam  mo¬ 
del  is  defined  as  the  elapsed  time  on  the  project  up  to  the 
point  when  the  system  reaches  full  operational  capability, 
but  not  including  the  system  definition  and  functional 
design/specification  phases.  The  estimates  of  the  total  life 
cycle  in  man-years  and  the  development  time  are  then  used  to 
derive  an  equation  giving  the  ordinates  for  a  man-power  ex¬ 
penditure  curve  for  a  specific  project.  A  yearly  dollar 
costing  can  then  be  computed  for  the  project  by  muitipying 
the  ordinates  cf  the  man-pcwer  curve  at  each  year  by  the  av¬ 
erage  cost/man-year  to  arrive  at  a  dollar  cost/year  and, 
subsequently,  at  a  total  dollar  cost  for  the  project.  Put¬ 
nam  uses  the  Raleigh  equation,  which  has  been  empirically 
determined  to  fit  the  project  manpower  loading  profile  for 
large  projects  and  tc  bast  represent  Norden's  model.  The 
most  popular  form  cf  the  curve  is  the  derivative  form  and  is 
expressed  by: 
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(3.  1) 


2 

-at 

=  2Kate 

where 

y*  *  the  number  cf  man-years  of  effort  expended  per 
year, 

K  =  the  total  number  of  man-years  required  during 

the  life  cycle  of  the  project, 

a  =  the  curve  shape  parameter, 

t  =  the  elapsed  time  in  years,  and 

e  =  the  exponential  function. 

With  the  assumption  that  the  shape  of  the  curve 

is  somehow  related  tc  both  the  difficulty  of  a  particular 

development  and  tc  the  skill  level  of  the  project  team,  a 

means  for  expressing  these  relationships  in  terms  of  Bay- 

leigh  curve  parameters  was  derived.  The  relationship  of  the 

parameter  a  to  development  time  (t  )  is: 

d 

2 

a  =  1/2t  (3.2) 

d 

which,  when  substituted  into  the  derivative  form  of  the  Hay- 

leiqh  curve,  results  in  the  following  equation: 

2  2 
-(*  /2tfl  ) 

y '  =  K/t  te  (3.3) 

a 
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To  use  the  above  equation,  estimates  must  be 

found  for  the  total  life  cycle  in  man-years  (K) ,  and  tae 

development  time  (t  ) .  Virtually  every  parametric  software 

d 

cost  model  is  based  on  an  estimate  cf  computer  program  size, 
measured  in  either  source  statements  or  object  code  instruc¬ 
tions.  Putnam  uses  source  statements  because  that  is  what 
programmers  produce.  Likewise,  it  simplifies  the  mathemati¬ 
cal  computations  because  compiler  efficiencies  are  not  con¬ 
sidered.  The  relationship  that  is  used  by  Eutnam  to  equate 
source  statements  to  development  time  and  project  effort  is 
given  by  the  following  equation: 


Ss 


Ck*K 


(V3) 


t 

d 


where 


(3.4) 


Ss  *  delivered  source  lines  of  code,  and 
Ck  *  state-of-technology  constant. 

Within  the  model,  estimating  program  size  is 
viewed  as  an  iterative  process  that  should  be  recomputed 
several  times  during  the  system  definition  and  functional 
design/specification  phases  in  the  software  life  cycle.  The 
first  estimate  is  done  at  project  conception  and  can  be  lit¬ 


tle  more  than  a  best  guess  used  tc  establish  basic  economic 


feasibility  based  on  past  software  projects  and  expert  opin¬ 
ion.  As  more  knowledge  is  gained  a  rout  the  project,  indivi¬ 
dual  segments  of  the  systea  are  estiaated  seperateiy  and 
then  totaled  to  give  a  aore  accurate  estiaate  of  the  expect¬ 
ed  size.  Also,  standard  deviations  and  confidence  intervals 
are  derived  frca  statistical  methods  that  use  best  and  worst 
case  estimates. 

To  determine  the  technology  constant,  data  from 
past  software  projects  must  be  inserted  into  the  software 
equation  (3.4)  tc  derive  the  unknown  variable  Ck.  It  should 
be  noted  that  Ck  is  initially  very  difficult  to  determine 
but  should  remain  consistent  for  similar  projects  within  a 
specific  organization.  After  the  parameters  ss  and  ck  are 
determined,  various  values  of  t^  and/or  K  may  be  substituted 
into  the  software  equation  to  produce  a  parametric  graph 
showing  size  versus  effort  and  time  (figure  3.1). 

A  constraint  line  determined  by  management  and 
representing  a  difficulty  gradient  for  certain  types  of  pro¬ 
jects  is  then  superimposed  on  the  graph.  Values  mat  fall 
below  this  line  are  determined  to  be  infeasible  for  software 
development . 

After  values  and  ranges  are  found  for  t  and  k, 

d 
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Figure  3.T.  Size  vs.  Effort  and  Time  Relationship 

dollar  costs  for  the  project  nay  be  coaputed  by  multiplying 
plying  an  average  labor  rate  per  nan-year  by  an  expected 
value  of  man-years  tc  derive  an  estimated  total  cost  for  a 
project.  A  variance  estimate  for  dollar  costs  may  be  oo- 
tained  in  a  similar  manner  from  the  variance  of  man-years. 
While  this  model  recognizes  that  real  world  managerial 
constraints  exist,  they  are  not  explicitly  addressed.  In¬ 
stead  it  is  recommended  that  linear  programming  techniques 
should  be  used  to  account  for  everyday  concerns  such  as 
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contract  deadlines,  cost  ceilings,  and  hiring  practices  and 
c  apabilities. 

b.  Application  to  Maintenance  Costing 

Putnam’s  aodel  takes  a  macro  approach  to  answer¬ 
ing  the  questions  nest  often  asked  by  aanagers  concerning 
the  areas  of  tine,  effort,  and  cost.  According  to  relation¬ 
ships  determined  empirically,  an  overall  estimate  of  man 
power  is  obtained  and  subsequently  allocated  among  the 
different  phases.  To  determine  the  risk  involved  in  the  es¬ 
timation,  statistical  methods  are  used  which  give  the  manag¬ 
er  a  'feel'  for  the  accuracy  of  the  data  presented  to  him. 

As  work  proceeds  during  the  life-cycle,  uncer¬ 
tainty  about  the  management  parameters  decrease.  In  order 
to  follow  and  track  the  time-varying  behavior  of  a  software 
system,  empirical  data  must  be  collected  and  plotted  to  show 
the  current  labor  force  for  any  given  time  (figure  3.2). 
Using  this  data  stream,  time  series  analysis  can  be  done. 
By  turning  the  characteristic  Hayieigh  behavior  into  a 
straight  line,  the  actual  manpower  data  may  be  fitted  to  get 
a  revised  estimate  of  future  resource  consumption. 


The  linear  form  of  the  Rayleigh-Nor den  curve  is 
illustrated  in  figure  3.3.  This  form  may  be  obtained  by  di¬ 
viding  equation  3.3  by  t  and  taking  the  natural  logorithm  of 
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II 


Time  or  PY 


Figure  3.2.  Typical  Plotting  Structure 
the  result.  This  yields 


2  2  2 

Ln(yVt)  *  <-1/2t  )t  ♦  Ln(K/t  )  (3.5) 

d  d 


which  fits  the  familiar  linear  fora  y  =  ax  *■  b. 


Actual  data  is  set  up  in  a  table  fora  with  addi¬ 


tional  calculated  data  points  that  are  needed  for  the  cor¬ 


responding  plot.  Hypothetical  data  from  Table  IV  is  plot¬ 


ted  in  figure  3.3  with  the  best  straight  line  fitted  to  the 


data  points  (determined  by  eye  or  calculation). 


Prom  this  plot,  Rayleigh  parameters  can  be  cal¬ 


culated.  The  slcpe  can  be  used  to  compute  development  time 

(t  ),  while  the  intercept  (K/t  )  ,  giver,  the  value  of  t 
d  d  d 

just  obtained,  yields  the  value  of  total  effort,  K.  Calcu¬ 
lations  for  determining  these  values  are  listed  with  the 


figure. 


t>5 


TABLE  IV 


Hypctbeical  Project  Data 


+- 

y 

y#/t 

t 

Ln(y'/t) 

1 

1 

68 

68.0 

1 

4.22 

1 

2 

70 

35.0 

4 

3.55 

1 

3 

106 

35.33 

9 

3.56 

1 

4 

118 

29.50 

16 

3.38 

1 

Projected  management  estimates  can  be  calculated 
by  extending  the  line  to  subsequent  year  points  (figure 
3.4).  Continuing  with  the  same  example  data,  future  man¬ 
loading  predictions  are  made  by  applying  the  sequence  of 
equations  contained  in  figure  3.4. 

Similiarly,  resource  estimation  for  additional 
outyears  may  be  computed.  As  mentioned  earlier,  this  model 
is  an  iterative  procedure.  Each  year  actual  project  data  is 
added  to  the  table.  The  data  points  are  replotted  and  the 
best  fit  straight  line  is  again  determined.  New  values  for 
the  slope  and  intercept  are  found  and  projections  are  then 
made  based  on  these  new  values. 


Ln(yV*)  I 


Slope. Calculations 

y“  ~-T  ~ 

Slope  - - —  =  — 

x  22 

2t 


take  reciprocals. 


2 

t  =22 
d 


2 

*  =11 

a 


3.32  years 


Intercept  calculatro ns 

I  =  4.  0  =  Ln  (K/t  )  =  q 
d 


2 

Ln  (K/t  ) 
d 

e  -  4.0 


2 

K/t  =  54.6 

d 


2 

K  =  54.6  t 

d 


K  =  54.6  *  11 


K  =  601  tnanyears 


Figure  3.3.  Pitting  the  3est  Straight  Line 


La (y  V*-) 


o 


Projection _f or  yea;  5 
y earS 

Ln(yVt)  =  2.85 
2.85 

y'/5  =  e 

o 

y ’  =  e  *  (5)  *  17.29  (5) 

y^  =  86  people  (manyear/y ear) 

Figure  3.4.  Lias  Extension  and  Prediction 

2.  Ar  my  Wacrcestiaatiag  Model 
a.  Description 

Realizing  that  there  was  a  need  for  a  simple, 
effective,  reasonably  accurate  procedure  for  estimating  and 
controlling  resources.  Army  Headquarters  analysts  produced  a 
comprehensive  aacroestiaating  procedure  for  allocating  the 
appropriate  manpower  commitment  to  an  application  system  at 


68 


any  point  in  the  system  life  cycle  [106].  The  procedure 
enables  users  tc  forecast  the  size  of  a  new  application 


software  project  and  suggests  the  manlcading  necessary  to 
accomplish  the  project  workload. 

Some  functional  estimators  for  the  project  man¬ 
ager  include: 

1)  optimum  man-loading  over  life-cycle; 

2)  total  manpower  over  life-cycle; 

3)  cost  per  year; 

4)  risk  prcfiles;and 

5)  scope  of  applicability. 

Initial  analysis  of  all  United  States  Army  Com¬ 
puter  Systems  Command  (USACSC)  systems  yielded  a  dataoase 
from  which  statistics  have  been  derived  that  permit  estao- 
lishment  of  control  limits  on  resource  allocation  at  any 
point  in  the  life-cycle  of  a  system.  Additionally,  numeri¬ 
cal  correlation  points  between  effort/unit  time  and  normal¬ 
ized  time  were  established  for  system  development  mile¬ 
stones.  Using  these  points,  the  project  manager  can  plot 
the  project  life-cycle  profile  of  a  software  development  ef¬ 
fort  in  terms  of  the  time  that  various  milestones  should  be 
reached  and  the  level  of  resources  (manpower)  that  should  be 
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applied  to  the  system  development  at  those  points  (figure 
3.5)  . 

Excursions  outside  statist ically  determined  control  liaits 
shown  in  figure  3.5  should  trigger  the  action  officer  to 
take  corrective  action. 

Using  the  mathematical  relationship  developed  by 


5J  orden, 

2 

-at 

y  *  =  2fCate 


(3.1) 


step-by-step  procedures  were  developed  for  estimating  system 

variables  for  the  following  cases. 

( 1 )  Case  £ :  System  already  under  development 

( resources  budgeted) .  Using  budget  data,  the  maximum  level 

of  manpower  (y‘  )  and  the  number  cf  years  to  reach  maximum 

max 

effort  (t  )  is  deterained.  Rather  than  compute  the  values 

y' 

max 

for  outyear  manpower  loading.  Table  7  is  used  to  compute  the 
values  of  y'  for  the  appropriate  t  .  .  By  multiplying  any 

y ' 

max 

entry  opposite  its  time  period  by  K,  the  appropriate  number 
of  manyears  are  obtained.  The  units  of  K  and  t  will  deter¬ 
mine  the  demensions. 
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MY/YR 


START 

t 

Y'  max 

tMaint 

0 

1 

2.38 

NORMALIZED 

TIME  (t/t 

Y ' max^ 

DESIGN  CEHTIFICATION 
first 
expected 
last 

0.235 

0.433 

0.618 

SYSTEMS  INTEGRATION 
first 
expected 
last 

TEST 

0.550 

0.660 

0.76  8 

PROTOTYPE  EVALUATION 
first 
expected 
las* 

TEST 

0.613 

0.800 

0.990 

EXTENSION 

first 

expected 

last 

0.613 

0.930 

1.250 

MAINTENANCE 

first 

expected 

2 . 096 

2.38 

last  2.853 


NOTE  1:  First  and  last  are  at  five  percent  probability  lev 
el..i.e.  there  is  a  ninety  percent  probability  tha 
t/tyaax  will  lie  between  first  and  last  for  a  par 
ticular  milestone  event.  If  net,  ask  questions. 

MOTE  2:  Tabular  entries  are  in  normalized  time  units. 


Figure  3.5.  Milestones  Applied  to  Project  Profile 
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TABLE  V 


Ordinates  for  Manpower  Punction 


|  1  2  3 

y' max  | 


50 

.  1250 

.  0556 

60653 

. 22062 

.  10510 

27067 

.30326 

.  17794 

03332 

.24349 

.20217 

00134 

.  13533 

.  18271 

00001 

.054  92 

.  13852 

.01666 

.09022 

.00382 

.05112 

.00067 

.02539 

.00009 

.01110 

.00000 

.00429 

.00000 

.00147 

.00044 

.00012 

.00002 

.00000 

.00000 

4  5  6  7 

.0310  .0200  .0139  .0120  | 

- , 

.06057  .03920  .02739  .020201 
.11031  .07384  .05255  .30918J 
.14153  .10023  .07354  .055651 
.15163  .11618  .08897  .069331 
.14307  .12130  .09814  .07906J 
.12174  .11682  .10108  .084801 
.09461  .10508  .09845  .08664| 
.06766  .08897  .09135  .08497| 
.04475  .07124  .08116  .080361 
.02746  .05413  .06926  .073561 
.01567  .03912  .05691  .065301 
.00833  .02694  .04511  .05634| 
.00413  .01770  .03453  .047291 
.00191  .01111  .02556  .03866| 
.00082  .00666  .08130  .03081| 
.00033  .00382  .01269  .023951 
.00012  .00210  .00853  .01817| 
.00004  .00110  .00555  .01346| 
.00001  .00055  .00350  .009741 
.00000  .00026  .00214  .00689| 
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(2)  Case  II:  New  system  (no  resource  data)  . 

Total  man-years  of  effort  and  peak  time  for  manpower  loading 
is  estimated  using  Bayes'  theorem.  [107]  Based  cn  empirical 
data  from  internal  systems,  a  probability  versus  K  density 
function  was  derived  without  regard  to  type  of  system. 
Purther  analysis  determined  frequency  of  system  type  and 
probability  of  occurence  of  each  type.  Using  estimates 
based  on  past  USACSC  experiences  (the  average  K  value  for 
all  systems  under  development  and  average  K  for  the  func¬ 
tional  type  of  system),  initial  estimates  for  a  new  new  de¬ 
velopment  are  calculated  from  regression  graphs.  Then,  by 
applying  Bayes'  theorem  tc  average  these  individual  esti¬ 
mates  in  the  weighted  probability  sense  yields  a  better  es¬ 
timate  of  K  with  a  smaller  standard  deviation  (i.e.  better 
confidence  in  th=  estimate) .  To  improve  estimates  and  re¬ 
duce  uncertainty,  Bayes'  theorem  is  sucessively  applied, 
b.  Application  to  Maintenance  Costing 

US AC SC  empirically  determined  that  all  of  tneir 
systems  reached  a  steady  level  of  effort  (maintenance  level) 
on  the  average  of  2.38  times  the  amount  of  time  that  was 
used  to  reach  maximum  effort.  This  relationship  can  be  ex- 


2.38 1 


(3.6) 


t 

saint  y* 

max 

In  applying  this  equation,  a  system,  with  maximum  level  of 
effort  reached  at  year  three,  mould  reach  a  steady  state  at 
7.14  years. 

The  level  of  effort  associated  with  the  steady 

state  maintenance  phase  was  empirically  determined  by  USA CSC 

to  be  twenty-three  percent  of  y*  with  a  ninty  percent 

max 

confidence  interval  from  eight  percent  to  thirty-eight  per¬ 
cent  of  y*  .  At  that  point  in  the  project  life-cycle, 
max 

when  2.38t  (twenty-three  percent  of  y*  )  is  rea ch¬ 

i' 

max  max 

ed,  using  numbers  generated  from  the  manpower  equation 

(3.1)  should  be  discontinued  and  a  constant  level  of  effort 

of  twenty-three  percent  of  y*  should  be  used  until  the 

max 

system  is  replaced.  Figure  3.6  shows  a  generalized 
control-limit  envelope  of  a  ninety  percent  confidence  inter¬ 
val  for  the  resource  level. 
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NORMALIZED  RESOURCES/UNIT  TIME 


/ 

Figure  3.6.  System  Resource-Control  Limits 

B.  SOFTWARE  EVOLUTION  MODEL 
1 •  Lahman-Belady  Model 
a.  Description 

There  have  been  several  attempts  made  to  assess 
resource  allocation  to  achieve  the  repair  or  modification 
required  for  a  single  release,  which  is  a  new  version  of  a 
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system.  A  variety  cf  data  has  been  collected  relating  to 
module  handle  rate  and  release  interval.  Based  on  experi¬ 
ence  in  dealing  with  different  environments,  it  has  been 
suggested  that  development  and  maintenance  trends  exist  giv¬ 
ing  rise  tc  complexity  measures.  These  measures,  in  turn, 
can  be  determined  by  the  average  number  of  old  module  Han¬ 
dlings  per  new  module  and  per  fault  fix,  respectively. 

As  systems  evolve  over  a  series  of  releases,  the 
ratio  of  changed  modules  tc  the  total  number  of  modules  have 
been  found  to  mcnotonicaliy  increase  and  approach  unity. 
This  ratio  is  an  observed  and  directly  measurable  guantity 
which  describes  the  system's  property  of  resistance  to 
change.  Of  importance  is  the  indication  that  the  number  of 
modules  involved  in  a  system  modification  is  likely  to  be 
proportional  to  the  effort  spent.  £  108,  109  ] 

Belady  and  Lehman  proposed  a  model  in  which  ac¬ 
tivity  is  of  three  kinds:  progressive  (£) ,  antigressive  (A), 
and  additional  work  related  to  system  complexity  (C) .  It 
was  hypothesized  that  a  balanced  budget  (B)  implies  that  at 
any  time 

B  =  P  ♦  A  ♦  C.  (3.7) 
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Although  simple,  the  nodal  captures  two  important  aspects  of 
evolution  dynamics;  the  sharing  of  the  resources  between 
progressive  and  antigressive  effort  (where  both  A  and  C  are 
considered  antigressive)  and  the  absorption  of  total  budget 
and  further  growth  limitation  by  the  inevitable  rise  in  the 
cost  of  complexity. 

Increase  of  C  activity  is  hypothesised  to  stem 
from  neglect  of  A  activity.  Removal  of  resulting  cumulative 
neglect  can  be  accomplished  only  by  a  temporary  increase  in 
A.  If  the  total  budget,  B  is  limited,  the  result  is  a  tem¬ 
porary  decrease  in  progressive  activity,  p.  It  is  assumed 
that  B,  P,  A,  and  C  can  be  measured  in  cost  per  unit  time. 
The  cost  function  is  expressed  in  the  following  fashion: 


Cost  (t) 


0 


1  -  m)KP(r) 


dr 


(3.8) 


where 

KP  =  inherent  A  activity  required  for  each  unit  of 
P  activity  to  prevent  complexity  growth; 
m  =  management  factor,  the  fraction  of  KP  actually 
dedicated  by  management  tc  A  activity  (0<m<l)  ; 
and 


T~  a  time  constant. 


b.  Application  to  Maintenance  Costing 

Preliminary  analysis  and  simulation  have  been 
carried  out  using  a  non-linear  differential  equation  model 
of  evolution  dynamics.  It  has  been  found  that  the  model  is 
capable  of  reproducing  some  important  phenomena  observed  in 
data  that  can  be  related  to  observed  characteristics  of  the 
system. 

In  figure  3.7,  the  simulation  shows  that  the 
code  production  rate  (the  progressive  element)  increases  to 
a  maximum  of  about  225  modules  per  year.  At  the  end  of  the 
first  year,  the  complexity  has  increased  to  the  point  where 
such  a  production  rate  cannot  be  sustained  with  the  budget 
available,  since  an  increasing  resource  demand  is  being  made 
by  A  and  C  activity.  A  balanced  budget  requires  a  reduction 
in  P  activity,  which  later  leads  to  a  reduction  in  A  activi¬ 
ty.  By  year  six,  the  system  has  reached  its  limiting  size 
with  the  resources  available. 

Although  results  seem  promising,  a  great  deai  of 
work  must  be  done  before  practical  results  in  the  form  of  an 
accurate  predictive  model  can  be  achieved.  From  figure  3.7, 
it  would  seem  apparent  that  application  of  control  theory 
to  modules  developed  earlier  may  result  in  a  substantial 
payoff  in  financial  terms. 
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Time  (years) 

Pigure  3.7.  Growth  Rate  Simulation 

2 .  Pur  Model 

a.  Description 

Putnam  and  Norden  have  prepared  a  Sayleign  curve 
model  for  the  rate  at  which  resources  are  consumed  by  soft¬ 
ware  engineering  projects.  One  of  the  model's  main  assump¬ 
tions  is  that  the  initially  rising  work  rate  is  due  to  a 
linear  learning  curve  governing  the  "skill"  available  for 
solving  problems  at  time  t.  This  assumption  is  questionable 
because  a  linear  learning  curve  is  not  theoretically  sup¬ 
ported,  and  the  skill  available  on  a  project  depends  on  the 
resources  which  have  been  applied  to  it  [110].  Thus,  this 


assumption  confuses  intrinsic  constraints  cn  the  rate  at 
which  software  can  be  produced  with  management's  economical¬ 
ly  governed  choices  on  how  to  respond  to  these  constraints. 

Parr  asserts  that  the  rate  of  progress  on  a 
software  project  is  primarily  determined  by  dependencies 
among  the  problems  which  must  be  solved.  Seme  problems  can 
be  solved  in  parallel  whereas  others  can  only  be  handled  se¬ 
quentially.  Let  W (t)  be  the  number  of  problems  whicn  have 
been  solved  at  time  t  and  V  (t)  be  the  number  of  visible  un¬ 
solved  problems  at  time  t  which  can  be  solved  (i.e.,  all 
earlier  required  problems  solved) .  When  a  problem  is  solved, 
W  (t)  increases  by  1;  V (t)  ,  however,  may  increase  or  decrease 
depending  cn  whether  or  net  the  problem  solved  makes  new 
problems  invisible/solvable.  It  is  reasonable  to  assume 
that  problems  solved  early  in  the  project  will  lead  to  mere 
unsolved  problems,  and  that  those  solved  later  will  have  a 
higher  probability  of  not  making  new  unsolved  problems  visi¬ 
ble.  K  crude  approximation  to  this  is  to  assume  that  the 
probability  of  a  solved  problem  not  generating  more  unsolved 
problems  is  linearly  proportional  to  the  number  cf  problems 
solved.  [  111  ] 
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How  dees  the  above  relate  to  the  rate  at  wnich 
development  programs  can  be  made?  Clearly,  management  can 
reduce  the  rate  of  progress  by  supplying  inadequate  re¬ 
sources.  There  is  also  an  upper  bound  to  the  amount  of  ef¬ 
fort  which  can  be  usefully  applied.  Sapid  progress  using 
large  amounts  of  input  resources  is  possible  only  when  there 
is  scope  for  solving  problems  in  parallel.  In  practice,  a 
different  programmer  (or  possibly  a  team  of  programmers)  can 
be  assigned  to  each  separate  visible  unsolved  problem.  This 
suggests  that  the  rate  at  which  useful  work  can  be  applied 
is  proportional  to  V  (t)  ,  and  that  with  this  '•optional"  input 
effort,  steps  in  the  development  will  he  achieved  at  a  rate 
proportional  to  v  (T)  . 

Whereas  the  Rayleigh  model  proposes  taat  the 
rate  of  progress  will  be  proportional  to  the  skill  level  ana 
number  of  problems  remaining,  the  above  has  argued  that  it 
is  proportional  to  the  visible  unsolved  problem  set.  A 
mathematical  expression  yields: 

V(t)  =  (1/d)  seen"  ( (t  ♦  c^J/2)  (3.9) 

a  hyperbolic  function  symetric  in  t  with  an  integration  con¬ 
stant  c  ;  while  tne  Rayleigh  function  is: 

3 


-  t  /2 


3  1 


V  (t) 


y' 


=  te 


(3.10) 


2 

The  sech  model  closely  resembles  the  Rayleijh  model  in  the 


latter  half  of  the  curve,  but  the  front  tail  is  positive 


rather  than  zero  like  the  Rayleigh  (figure  3.8).  Thus,  in 
2 

the  sech  model,  projects  do  not  have  well-defined  starting 


points.  This  accounts  for  work  done  prior  to  the  official 


project  starting  date. 


workrate 


Figure  3.8.  Sech  Curve 


One  cf  the  principles  of  software  programming  is 
that  decisions  initially  made  should  be  high-level  struc¬ 
tured  ones  which  identify  components  for  subsequent  refine¬ 
ment.  Increasing  the  complexity  of  the  initial  decisions  in 
this  manner  is  equivalent  tc  varying  the  distribution  of  tne 
probability  of  a  solved  problem  generating  unsolved  ones. 
-/  modifying  the  assumption  that  this  probability  is  linear, 
::rr*d  workrate  function  can  be  derived: 
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V  (t)  = _ A_e xt_  d2_^t) _ (3.11) 

(1  ♦  A  exp  (-2  o4 1)  ) 

Thus,  it  may  be  seen  that  whereas  the  Bayleigh 
model  of  software  development  proposes  that  the  rate  of  pro¬ 
gress  will  be  proportional  to  the  skill  level  and  number  of 
problems  remaining,  this  section  has  argued  that  it  is  pro¬ 
portional  to  the  size  of  the  number  of  the  visible  unsolved 
node  set. 

Results  obtained  from  the  proposed  model  are 
similiar  to  the  Rayleigh  model,  except  that  account  is  taken 
of  work  contributing  to  a  project  waich  precedes  its  offi¬ 
cial  starting  date.  The  proposed  model  has  been  shown  to  be 
sufficiently  determined  for  it  to  be  possible  to  account  for 
the  effect  of  different  programming  methodologies  on  the  na¬ 
tural  work  associated  with  the  project. 

b.  Application  to  aaintenance  Costing 

?arr  suggests  that  exhaustion  of  the  problem 
space  is  the  main  cause  for  decrease  in  maintenance  effort 
at  the  end  of  the  project  profile  curve.  In  addition,  the 
structure  of  the  software  product  achieved  during  the  devel¬ 
opment  could  affect  the  project  work  profile.  While  appli¬ 
cations  to  maintenance  costing  have  been  addressed  in 
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concept:  only,  implications  are  that  integration  technigues 
for  determining  the  area  under  the  curve  at  a  specific  time 
pe-  riod  will  produce  results  similar  to  those  obtained  by 
using  Putnam's  model. 

C.  CHAPTEB  SUMMABY 

With  the  intent  to  gain  management  control  of  predicting 
maintenance  costs,  various  software  cost  estimating  methods 
and  philosophies  derived  from  observing  trends  and  patterns 
in  the  development  cycle  are  being  extended  to  encompass  to¬ 
tal  system  costs.  Supportive  evidence  for  the  accuracy  of 
the  models  discussed  herein  is  contained,  for  the  most  part, 
in  software  life-cycle  simulations.  It  is  anticipated,  how¬ 
ever,  that  the  acute  interest  and  increased  awareness  shown 
in  the  resource  investments  attributed  to  software  mainte¬ 
nance  will  be  viewed  more  critically.  Although  lacking  in 
substantial  procf  for  predictive  validity,  these  models 
serve  as  stepping  stones  in  producing  a  composite  model  for 
tracking  maintenance  costs. 
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IV.  MAMSiiiS  SOFTWARE  MAINTENANCE  COSTS 

Previous  chapters  have  addressed  topics  that  are  being 
critically  examined  for  their  inpact  on  the  software  mainte- 
nance  phase.  They  also  discussed  the  application  of  current 
development  software  cost  estimation  techniques  for  obtain¬ 
ing  maintenance  costs.  The  focus  of  this  chapter  will  be 
the  presentation  of  a  method  for  arriving  at  a  well- 
structured  view  of  the  management  of  the  maintenance  phase 
of  the  software  life-cycle.  While  a  mathmatical  model  which 
accurately  explains  the  phenomena  of  the  maintenance  phase 
still  remains  elusive,  a  planning  and  control  model  has  been 
developed  to  aid  project  managers.  The  structure  of  the  mo¬ 
del  embodies  two  distinct  concepts: 

1)  a  planning  concept  -  development  of  the  management 
strategy  to  cement  the  perceptions  of  the  maintenance 
issue ; 

2)  a  control  concept  -  procedural  analysis  for  estimating 
the  maintenance  manloading  requirements. 

Subsequent  sections  will  address  application  of  each  as¬ 
pect  of  the  model  in  depth. 
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A.  PLANNING  CONCEPT 

1 •  Project  Management 

Primary  responsibility  for  development  of  a  manage¬ 
ment  strategy  belongs  to  the  project  manager  designated  to 
manage  the  system  plan.  As  project  manager,  one  must  ini¬ 
tially  determine  and  define  the  maintenance  requirement  of 
the  mission  profile  for  the  system  that  is  to  be  designed 
(i.e.  built-in  maintainability). 

Factors  which  must  be  considered  early  in  the  formu¬ 
lation  of  a  maintenance  plan  include: 

1)  Probability  of  change  in  requirements,  ahile  it  may  be 
impossible  tc  define  adequately  the  complete  require¬ 
ments  for  a  large  program,  viewing  the  type  of  system 
application  (business,  scientific,  command  and  control) 
and  utilization  rate  will  serve  as  indicators  for  the 
amount  of  flexibility  to  be  considered  in  the  system 
design. 


2)  Software  performance  requirements.  Again,  application 
type  is  the  dictating  force  for  analyzing  this  factor. 


3)  Hardware  life-cycle.  In  planning  for  software  mainte¬ 
nance,  the  interaction  of  the  aardware  and  software 
life-cycle  must  be  taken  into  account. 


2 .  Objectives  of  the  Maintenance  Concept 

Derivation  of  maintainability  requirements  from  the 
description  of  the  operational  requirements  provides  tae 
support  planning  criteria  on  which  to  base  the  maintenance 
concepts  appropriate  to  the  maintainability  requirement. 
The  maintenance  concept,  which  basically  defines  criteria 
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governing  the  scope  and  methods  applicable  at  each  echelon 
of  maintenance,  attempts  to  satisfy  the  quantitative  main¬ 
tainability  requirement  derived  for  the  system  and  the  plan¬ 
ned  support  environment  within  which  the  system  will  oper¬ 
ate.  Early  development  cf  the  appropriate  maintenance 
concept  will  provide  a  definitive  and  uniform  basis  for  ac¬ 
complishing  the  system  design  and  support  planning  tasks. 

3.  Establishing  the  Maintenance  Policies. 

System  effectiveness  is  jointly  dependent  on  several 
parameters,  of  which  performance  characteristics,  system  re¬ 
liability,  and  operational  availability  appear  to  be  the 
most  critical.  In  effect,  these  parameters  set  baseline  re¬ 
quirements  or  constraints  which  may  have  impact  upon  the  de¬ 
sign  process  depending  upon  the  maintenance  policy  that  has 
been  established.  While  a  boundless  number  of  policy  varia¬ 
tions  may  exist,  the  following  four  categories  identify  the 
range  of  policy  choices.  Ihe  basic  distinction  among  these 
four  categories  lies  in  the  amount  of  resources  invested 
over  time  and  the  cumulative  benefit  received  over  time. 
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a.  Category  I  -  No  Management  Control 

A  steady  maintenance  effort  is  applied  with  no 
attempt  for  configuration  control  which  is  ensuring  that  a 
master  copy  of  all  operational  software  is  maintained.  Com¬ 
plexity  of  the  program  will  eventually  reach  the  point  where 
locating  errors  and/or  making  changes  becomes  exceptionally 
difficult.  Gradually,  the  program  becomes  less  useful  until 
it  must  be  discarded  and  a  new  program  developed.  This 

policy  may  prove  to  be  cost  effective  for  situations  where 

it  is  known  that  the  nature  of  the  application  will  limit 

the  useful  life  cf  the  program. 

b.  Category  II  -  Permanent  Support  Level  with 

Periodic  Hede velopmect 

As  in  Category  I,  a  steady  level  of  maintenance 
support  is  provided  by  a  permanent  workforce.  Redevelopment 
or  a  new  release  can  be  planned  for  at  regular  intervals  or 
in  response  to  a  specific  guantity  of  change  requests. 

c.  Category  III  -  Error  Repair  with  Major  Changes 
Manpower  support  is  set  at  the  level  needed  to 

correct  program  tugs.  External  programming  support  would  be 
required  for  making  major  changes. 
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d.  Category  IV  -  Error  Repair  Only  with  Periodic 
Redesign 

As  in  Category  III,  manpower  is  set  at  the  level 
needed  to  correct  an  unacceptable  design  error  or  program 
bug.  Change  requests  are  used  in  establishing  specifica¬ 
tions  for  subsequent  design  of  a  new  program. 

4 .  Management  Structure 

Since  the  level  of  repair  policy  must  be  compatable 
with  the  maintainability  requirement,  the  maintenance  con¬ 
cept  must  be  defined  for  each  management  level  of  mainte¬ 
nance  established.  Beginning  with  the  lowest  level  of  us¬ 
ers,  maintenance  concepts  are  implemented  with  subsequent 
policies  for  higher  management  levels  developed  to  support 
the  user  level  concept.  To  illustrate,  maintenance  may  be 
divided  into  three  echelons  as  discussed  below  and  shown  in 
figure  4.1. 

1)  User  level.  Maintenance  may  be  restricted  to  failure 
reports  and  system  restarts. 

2)  Organizational  level.  Technicians  perform  corrective 
maintenance.  Tasks  performed  would  include  location  of 
fault,  module  repair,  and  testing. 


3)  Contractor  level.  Maintenance  performed  at  this  level 
may  be  used  to  supplement  (augmented  support)  or  to 
replace  (sustained  support)  the  organizational  ievei 
support. 


Activity 

User 

Level 

Organization 

Level 

Contract 

Level 

Where 

performed 

_  .  _ 

Bemote  or 
local  site 

Facility 

having 

project 

cognizance 

Agency  and/ 
or  contract 
facilities 
as  required 

Who  performs 

Maintenance 

personnel 

Maintenance 
division  or 
support  team 

Contract 

personnel 

Ma  xntenance 
action 

Restore 
system  to 
operat ional 
status 

Locate  mod¬ 
ule  errors; 
repair  and 
return  to 
user 

Locate  mod¬ 
ule  errors; 
repair  and 
return  to 
user 

Maintenance 

tasks 

Inspection 
and  restarts 
minor 

repairs  and 

adjustments 

submit 

change 

reguests 

Module 
reoair; 
major  coding 
modifica¬ 
tions, 
testing 

Complex 
repairs, 
modifica¬ 
tions;  major 
coding: 
rebuilds 

Pigure  4. 1-  Maintenance  Levels 
5.  System  Life-cyc^le  Objectives 

Utimately,  the  maintenance  objective  is  to  achieve 


the  required  level  of  maintainability  in  delivered  systems 
with  an  optimum  balance  between  resource  support  require¬ 


ments  and  potential  life-cycle  costs.  In  order  to  meet  this 
objective,  it  is  necessary  to  begin  the  system  life-cycle 
with  the  appropriate  conceptual  approach.  As  the  software 


product  passes  through  several  distinct  phases  in  its  evolu¬ 
tion,  maintenance  prospects  can  be  enhanced  if  adequate  at¬ 
tention  is  taken  in  each  phase. 
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Figure  4.2  depicts  the  life-cycle  as  a  simple 
phase-to-phase  flow  diagram,  joined  by  critical  transition 
points  where  it  can  be  ascertained  that  the  required  main¬ 
tainability  objective  has  been  achieved  before  transition  to 
the  next  phase.  These  transition  points  are  denoted  in  the 
figure  as  major  achievement  milestones.  Each  phase  compris¬ 
es  several  areas  cf  management  endeavor  in  which  the  consid¬ 
eration  of  the  system  maintainability  is  essential  to  the 
attainment  of  milestone  objectives.  The  software  product  is 
re-examined  at  each  milestone  to  determine  the  future  course 
based  on  progress  up  to  that  point.  As  each  milestone  ob¬ 
jective  is  met,  maintainability  becomes  progressively  more 
tangible  as  a  built-in  feature  of  design.  Maintainability 
milestone  requirements  are  summarized  in  the  figure. 

Milestone  criteria  can  best  be  satisfied  by  syste¬ 
matic  application  of  approved  procedures  in  the  performance 
of  evaluation,  management,  and  control  tasks  which  are 
geared  directly  to  specfic  objectives  cf  individual  mile¬ 
stones  in  the  life-cycle.  A  basic  approach  to  maintainabil¬ 
ity  achievement  as  an  evolutionary  phase-to-phase  'growth* 
process  is  shown  in  figure  4.3. 


91 


/operational 

Vreguirsments^ 


I 


I5| 

¥ 


Concept!  -  — -  -  -  -  -  -  j  Service! 

forau-  }■»  1 1  J Design  |>  1 2)^|Code|  >|  3f>|  Test  1 4  j-»  j  use  | 
lation  j  -  -  -  -  -  -  -  - 


Concept  Foraulation  Phase  Milestone  Criteria.  Maintain¬ 
ability  requirements  derived;  maintenance  concept  estao- 
lished;  maintainability  documented  in  system  specifica¬ 
tions;  maintainability  milestones  and  task  requirements 
documented. 

(1)  Proceed  to  design  phase. 

Design  Phase  Milestone  Criteria.  Maintainability  design 
approach  and  maintenance  concept  optimized  by  tradeoff  and 
conformance  to  specified  requirements  and  economic  consid¬ 
erations;  maintainability  requirements  and  milestone 
criteria  updated. 

(2)  Proceed  to  code  phase. 

Code  Phase  Milestone  Criteria.  conformance  tc  specified 
maintainability  requirements  and  maintenance  concepts  ver¬ 
ified  by  evaluation;  maintenance  control  procedures  de¬ 
fined  in  support  documentation. 

(3)  Proceed  to  test  phase. 

Test  Phase  Milestone  Criteria.  Maintainability  degrada¬ 
tion  factors  verified  by  test  and  evalution;  maintenance 
concepts,  repair  policies,  and  maintenance  procedures 
are  verfied. 

(4)  Software  product  is  approved  for  delivery. 

Service  Ose  Phase  Milestone  Criteria.  Maintainability 
characteristics,  maintenance  prodecures,  and  support  costs 
determined  by  periodic  assessment  cf  management  data; 
problem  areas  identified  for  correction. 

(5)  Initiate  change  request.  product  enhancement  or  new 
development;  repeat  life-cycle. 


Figure  4.2.  Maintenance  Milestones  in  the  System  tife-cycle 


3.  CCNTHOI  CONCEPT 

1  •  Objective  oj  Maintenance  Control 
The  objective  of  this  thesis 
methodology  for  arriving  at  a  good 
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TASK  AREA 


Determine 
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Show  ade¬ 
quacy  of 
maintain¬ 
ability  in 
develop¬ 
ment 


Achieve 

optimum 

mainte¬ 

nance 

support 


0  Establish  S  policies 
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0  Optimize  N  to  relia-  1 
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and  supportability 
°  Evolve  conceptual 
design  criteria 

°  Define  M  requirements  j 


°  Define  n  requirements  I 
0  Define  M  milestone 
criteria  and  task 
requirements  in 

frcgram  documentation 
pecifically  outline 
foregoing  requirements! 
in  contractual 
documents 


0  Identify  and  define  M  j 
problems  and  critical  | 
areas 

°  Integrate  n  enhance¬ 
ment  into  design 
°  Verify  design  conform¬ 
ance  to  specific 
requirements 
°  Review  impact  of  pro¬ 
posed  changes  on  M 
design  characteristics! 


°  Prepare  detailed  plans 
for  maintenance  test 

°  Demonstrate  adequacy 
of  maintenance  manuals 


°  Develop  mamtainence 
plan,  repair  policies, 
and  procedures 
°  Develop  maintenance 
training  program 
°  Prepare  contractor 
support  plan 


CP  =  Concept  Formulation  D  =  Design 
C  =  Code  I  =  Test 

S  *  Service  Use 

Figure  *.3.  Maintenance  Tasks  in  the  System  Life-cycle 
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maintenance  costs.  Determining  the  requirements  for  pure 
maintenance  is  considered  valuable  in  that 

1)  estimates  can  be  calculated  of  the  manloading  necessary 
to  form  a  maintenance  support  team  which  is  composed  of 
either  in-house  or  contract  augmentation; 

2)  projections  can  be  made  for  outyear  maintenance  support 
and  availability  of  manpower  resources  for  developmen¬ 
tal  work. 

With  future  research,  the  application  of  this  model 
may  be  extended  to  any  software  project;  however,  access  and 
availability  of  data  precluded  analysis  of  small  and  medium 
sized  projects.  Only  data  from  major  projects  was  analyzed 
for  developing  a  computational  algorithm. 

In  executing  the  computational  algorithm,  both  macro 
(system)  and  micro  (functional  area  component)  techniques 
are  used  concurrently  tc  increase  the  validity  of  the  esti¬ 
mates.  An  implicit  assumption  worth  noting  is  that  each 
method  should  provide  reasonably  close  estimates  for  the 
same  project.  The  macro  technique,  of  course,  is  based  on 
total  system  characteristics  and  will  provide  the  gross  man¬ 
ning  requirements  directly.  Alternately,  from  the  micro 
technique,  summation  of  the  decomposed  functional  areas  will 
yield  the  gross  manning  for  the  total  system. 
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2.  Model  Deriviaticn 


The  data  under  study  was  taken  from  a  large-scale 
project  reported  by  USACSC  (112]  and  unpublished  data  from 
the  IBM  Space  Shuttle  Program  (113]. 
a.  Macro  Technique 

Using  the  Rayleigh  curve  parameters  derived  by 
Norden  and  Putnam  (114,  115],  a  method  was  constructed  for 

obtaining  total  system  maintenance  requirements  applicable 
to  the  established  management  strategy.  In  his  early  work, 
Norden  made  note  of  the  fact  that  the  Rayleigh  curve  of  a 
project  profile  has  a  point  of  inflection  at  which  the  de¬ 
crease  in  utilized  manpower  slows  down  in  the  descending 
portion  of  the  curve. 


1/2 


where 

t  *  the  inflection  point  of  the  project  carve 

ip 

a  =  the  shape  parameter  or  spread  of  the  curve. 


The  point  of  inflection  may  have  more  signifi¬ 
cance  than  originally  recognized.  If  it  can  be  shown  that 
the  level  of  effort  for  the  maintenance  phase  reaches  a  max¬ 
imum  at  this  point,  the  manlcading  estimate  calculated  from 
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this  point  can  ie  used  as  the  upper  bound  for  maintenance 


support.  In  essence,  the  current  model  suggests  a  new 
mechanism  for  determining  the  level  of  maintenance  support 
required.  Gained  from  the  model  is  the  benefit  of  relating 
the  work  profile  more  directly  to  the  intrinsic  structure  of 
the  project  profile. 

To  simplify  calculations,  the  project  profile  is 

normalized  with  respect  to  t  and  y*  as  shown  in  figure 

d  max 

4.4.  Total  life-cycle  (K) ,  has  a  normalized  value  of  1. 
Based  on  this  assumption  and  using  Sayleigh  curve  relation¬ 
ships,  it  can  be  shewn  empirically  that  the  peak  of  mainte¬ 
nance  effort  occurs  at  the  inflection  point. 


From  the  normalized  curve  values,  the  shape 


parameter  is  found  with  the  following  relationship: 


a  =  -  =  C.5 

2 

2t 

d 


(4.2) 


Substituting  this  value  of  a  in  the  following  equation,  the 

inflection  point  (t  )  of  the  project  profile  is  obtained. 

ip 


/  0/2 

„  •  ■ 


1.73  years. 


(4.3) 


Manloading  requirements  at  time  t  (y*  ) 

ip  1.73 

can  be  shown  mathematically  to  be  equal  to  the  maximum  man- 

load  (y*  )  which  occurs  at  tne  peak  (t  )  of  the  maintenance 

t  m 

m 

phase  profile.  Stated  in  the  format  of  a  mathmatical  equa¬ 
tion,  this  equality  has  the  form 


(project  inflection 
point  manning) 


(maximum  maintenance 
phase  manning) 


(4.4) 


Substituting  normalized  values  into  the  Rayleigh  (manpower) 
equation 


y*  =  2in  <*05>  <1*73>6 


(-.  05)  (1.73) 


(4.5) 


y*  =  0.38  manyears. 

(1.73) 


(4.6) 
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In  order  to  calculate  maximum  Banning  for  the 

maintenance  phase,  parameters  for  the  maintenance  curve  must 

be  defined.  Actual  time  elapsed  between  the  beginning  of  the 

maintenance  phase  (t  )  and  the  maximum  level  (t  )  is  comput- 

o  a 

ed  using  eapirical  data  recorded  by  QSACSC.  Hesults  from 

the  OSA CSC  research  indicate  that  the  maintenance  phase, 

which  accounts  for  twenty  percent  of  the  total  life-cycle 

manpower  (K)  ,  begins  at  approximately  1.3  years  normalized 

time.  With  this  estimation,  actual  time  elapsed  (t  *  can  be 

e 

found  by 

t  =  t  -  t  =  0.43  years.  (4.7) 

e  a  o 

The  spread  of  the  maintenance  curve  (a  )  is 

a 

determined  by  suttituting  the  elapsed  time  value  into  the 
already  familiar  equation 

1 

a  - -  =2.71  (4.8) 

m  2 

2<t  ) 
e 

The  value  obtained  for  the  shape  parameter  suggests  a  curve 
having  a  wide  spread,  an  expected  characteristic  of  the 
maintenance  phase  profile  curve.  Computation  of  the  max  ■ 
manloading  for  tae  maintenance  phase  iroa  the  basic  manpower 
equation  gives 
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y'  =  2  (.2K)  (2.71)  (.43)  6 

) 

a 


(-2.71)  (.43) 


(4.9) 


y '  =  0.38  =  y* 

(t  )  (t.  ) 

o  ip 


(4.  10) 


With  y*  defined  to  be  the  upper  boundary  for 


the  maintenance  effort,  another  boundary  can  be  identified 

as  the  lower  limit  for  maintenance  effort.  8y  determining 

the  value  of  the  inflection  point  of  the  maintenance  curve 

(t  )  ,  a  minimum  support  level  can  be  found  from 
im 


=  .74  years. 


Converting  this  time  to  normalized  time  (t  ) 

n 


(4.11) 


t  =  t  ♦  t 
n  o  im 


(4. 12) 


t  =  1.3  ♦  .74  =  2.04  years 
n 


(4.13) 


and  substituting  this  value  in  the  manpower  equation  yields 


y*  =  .25  manyears. 

(2.0«) 


(4.  14) 


The  manpower  loading  calculated  for  the  inflec¬ 
tion  point  of  the  maintenance  phase  (t  )  closely  approxi- 

im 

mates  the  value  identified  by  USACSC  as  the  steady  state 
level  of  effort.  Establishing  maintenance  at  the  minimum 


level  can  be  interpreted  as  a  Category  IV  policy. 


r 


b.  Hicrc  Technique 

Deco mposition ,  aore  commonly  referred  to  as  the 
work  breakdown  structure  (MBS)  method,  has  been  a  predomi¬ 
nate  methodology  for  estimating  manning  resources.  A  system 
is  considered  to  contain  subsystems  which  are  further  divid¬ 
ed  into  smaller  hierarchial  structures  until  the  smallest 
programing  element  is  reached.  Once  the  functional  areas 
are  defined,  characteristics  (complexity,  productivity,  er¬ 
ror  rate,  etc.)  of  each  must  be  reviewed  to  determine  the 
level  of  effort  needed  for  maintenance.  Appendix  A  contains 
an  example  of  a  micro-estimating  methodology  along  with  the 
sample  data  used. 

3 •  Sample  Application 
a.  Sample  Data 

Data  used  for  this  sample  application  of  the 
control  concept  was  provided  by  I  EH  Federal  Systems  Space 
Shuttle  Program  £116J.  The  raw  manning  data  is  provided  in 
Appendix  A.  The  remainder  of  this  section  is  a  step-by-step 
example  of  the  computicnal  algorithm  which  implements  the 
control  concept  of  the  proposed  model. 
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Project  Curve  Parameters 


K  *  1343 

a  =  .  08 

Y'  =  325 
max 


Maint enence  Support  Level 

(1)  Macro  technique 

t  *  4.33 

ip 

Y '  *  207  aanvears 

(4.33) 

t,  =5.1  years 


im 

y'  =  137  manyears 

(5.1) 


TOTE”!! - 

MSB  *  maintenance  support 
boundary 

Boundary  level  established 
fpom  analysis  of  nacre  and 
micro  estimations. 


(2)  Micro  technique 

y  *  component  manning 
c 

V*  y  =  195  manyears 
*-  c 


(refer  to  Appendix  A) 


b.  Computational  Algorithm 


Stap  J.  Fit  the  actual  budget  data  to  a  Ray¬ 
leigh  curve.  Figure  4.5  shows  plotted  data  for  the  Space 
Shuttle  program. 

Step  2.  Determine  aaintenance  support  boundary 
lines  by  calculating  the  inflection  points  of  both  the  pro¬ 
ject  profile  and  aaintenance  phase  curve. 

Step  3.  Deteraine  support  level  requirements 
using  micro-estiaating  techniques. 

Step  4.  Compare  values  obtained  froa  aacro  and 
micro  methods.  Analyze  the  differences  froa  an  economic 
standpoint  based  cn  aanageaent  policy. 

Step  5.  Predict  outyear  budget  requirements  for 
maintenance/new  development  contingent  on  management  policy, 
c.  Management  Applications 

Although  the  results  shown  here  relate  to  only 
one  set  of  data,  they  are  encouraging  in  the  support  tney 
give  the  model.  The  model  presented  in  this  thesis  could 
provide  a  direct  means  to  evaluate  the  impact  of  current  and 
future  management  practices  on  the  life-cycle  cost  of  tae 
software  system.  The  idea  of  the  development  of  a  mainte¬ 
nance  strategy  coupled  with  the  use  cf  the  computational 
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algorithm  provides  the  project  manager  with  some  powerful 
management  tools,  While  additional  research  is  warranted, 
it  is  purported  that  application  or  the  model  will  prove 
enlighting  in  the  following  respects. 

(1)  Detegg^ninq  Maintenance  Support  Level. 
Preliminary  estimates  obtained  from  inflection  point  predic¬ 
tors  may  be  used  as  a  starting  point  for  planning  workforce 
requirements  to  be  drawn  from  internal  assets.  Likewise,  if 
external  or  contracted  support  must  be  procured,  evaluations 
of  submitted  bid  proposals  will  be  necessary.  Although  yet 
unproven  statistically  for  accuracy,  the  inflection  point 

predictors  appear  to  define  maximum  (t  )  and  minimum  (t  ) 

ip  ia 

boundaries  for  maintenance  levels. 

In  accordance  with  the  type  of  maintenance 
strategy  chosen,  a  maintenance  level  boundary  can  be  select¬ 
ed.  For  example,  if  a  Category  IV  policy  is  selected,  man¬ 
power  needs  would  approach  the  minimum  boundary.  On  the 
other  hand,  a  Category  I  policy  would  require  resources  ap¬ 
proximated  by  the  maximum  level.  With  these  boundaries  to 
serve  as  guidelines,  contract  proposals  can  be  viewed  more 
critically. 
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(2)  Forecasting  Resource  Distribution.  Whether 
an  internal  or  external  workforce  is  used,  planning  and 
budgeting  estimates  of  aanloading  are  usually  projected  for 
discrete  timeframes.  During  the  maintenance  phase  of  a  via¬ 
ble  project,  the  workforce  in  terms  of  total  number  remains 
stable;  however,  the  work  distribution  or  functional  roles 
of  personnel  may  change  (i.e.  programmers  may  shift  from 
maintenance  work  to  development  work) .  Within  governmental 
agencies,  this  stability  may  be  attributed  to  fixed  contract 
levels  or  established  manning  levels,  neither  of  which  can 
be  easily  changed.  therefore,  the  management  problem  be¬ 
comes  one  consisting  not  only  of  how  many  personnel  are 
needed,  but  also  hew  can  assets  best  be  utilized. 

In  light  of  the  fact  that  the  users  have 
changing  requirements,  the  issue  of  workforce  allocations 
for  new  research  and  development  must  be  considered.  Based 
on  the  Rayleigh  curve  characteristics  for  a  specific  project 
and  using  a  fixed  support  level  environment,  approximate 
values  for  workload  distribution  can  be  calculated. 

By  method  of  integration,  the  proportion  of 
the  total  support  level  force  that  will  be  dedicated  to  pure 
maintenance  and/cr  new  development  in  future  timeframes  can 


be  calculated 


Figure  4.6  illustrates  this  point  using  the 


sample  data. 


=  101  MY  (resources  available  for  new  development) 

Note  Is 

MSB  *  maintenange  support  boundary.  In  this  example,  the 
boundary  is  established  at  the  project  profile  inflec¬ 
tion  point.  Alternately,  the  boundary  would  be  estab¬ 
lished  to  indicate  the  manning  level  of  the  mainte¬ 
nance  workforce. 


Figure  4.6.  Forecasting  Future  Requirements 


Maintenance 
oversight  method  is  twofold, 
work  (enhancements,  additions. 


information  gained 
The  separation  of 
new  design)  from 


with  this 
development 
maintenance 
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work  (debugging,  design  error  correction)  is  accomplished, 
-hereby  allowing  for  tetter  interpretation  of  the  project 
investment.  The  comparison  of  the  relative  proportion  of 
maintenance  manning  versus  development  manning  for  reviewing 
project  viability  can  also  be  made.  This  concept  will  be 
discussed  tore  fully  in  the  next  section. 

(3)  Monitoring  Configuration  Control.  A  pauci¬ 
ty  of  available  data  prevents  the  comparison  of  actual  and 
predicted  manpower  that  is  required  during  the  maintenance 
phase.  The  assumption  that  the  maintenance  tail  is  flat  or 
reaches  a  steady  state  seemingly  arose  from  this  lack  of  in¬ 
formation.  It  is  the  authors*  contention  that  new  releases 
of  a  software  product  may,  ir.  fact,  cause  increases  in  the 
maintenance  tail  ever  time. 

Lehman  and  fieiady's  [117,  118]  research, 
discussed  in  chapter  3,  gives  strong  indications  that  subse¬ 
quent  releases  for  a  software  product  increase  complexity 
and  the  amount  cf  antigressive  (maintenance)  work  that  is 
required  for  the  total  system.  Two  inherent  characteristics 
of  the  software  product  directly  affected  by  a  new  release 
are  the  system  configuration  and  the  size  of  the  system 
problem  space.  From  a  project  profile  view,  the  time  period 
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when  these  new  releases  occur  is  during  the  maintenance 
phase.  With  the  assertion  that  the  work  allocated  to  the 
completion  of  a  new  release  oust  he  considered  as  a  phase 
within  the  project  life-cycle,  the  increase  in  maintenance 
costs  can  be  explained. 

As  the  diagram  in  figure  4.7  indicates,  the 
changes  induced  ty  the  release  phase  will  cause  the  level  of 
aaintenance  to  increase.  Unless  carefully  monitored,  each 
new  release  may  cause  an  increase  in  the  maintenance  re¬ 
quirements  until  the  original  maximum  maintenance  support 
level  is  reached  cr  exceeded.  When  this  occurs,  management 
is  forced  to  make  a  cost-benefit  assessment  of  the  software 
system. 

Using  the  concepts  introduced  earlier  (in¬ 
flection  point  predictors  and  resource  distribution  fore¬ 
casting)  ,  maintenance  saturation  of  the  software  system  can 
be  detected.  The  support  line  obtained  from  the  inflection 

point  predicter  (t  )  serves  as  a  guideline  for  total  system 

ip 

saturation.  Management  policy  sets  forth  limits  for  corres¬ 
ponding  maintenance  and/cr  development  expenditures  which 
establishs  a  budget  saturation  level.  These  saturation 
levels  may  be  equal  cr  different.  In  an  attempt  to  preclude 
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NORMALIZED  PROJECT  P8CPILE 


-'l- 
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! 

max  | 


RELEASE  CYCLE 


/Release  if/////  Release  2  j 


Note  1: 


=  aaintenance  support  boundary 


=  svstem  saturation  level,  equivalent  to  curve  inflec¬ 
tion  point  where  any  aaintenance  above  this  level 


would  re  considered  antigressive 


budget  saturation  level,  established  by  aanagenent 
where  possible  values  nay  be: 
ast  =  ssl 

SSL  <  SSL 
ESL  >  SSL 


Figure  4.7.  New  Release  Effect  on  Maintenance  Level 


excessive  maintenance  costs,  the  saturation  lave!  viewed  as 
dominant  is  used  to  trigger  management ' s  attention  toward  a 
system  rebuild.  For  the  subsequent  rebuilt  system,  a  new 
Rayleigh  curve  is  plotted  and  a  new  cycle  of  planning  and 
cor to  1  begins. 


C.  CHAPTER  SUMMARY 

Presented  in  this  chapter  is  a  oilevel 
ing  software  maintenance  costs.  The  model, 
a  planning  concept  and  a  control  concept, 
creation  of  a  management  strategy  will  have 
fects  in  the  system  total  life-cycle  costs 
rently,  the  two  model  concepts  allow  fcr 
tion  of  maintenance  ob:ectives  between 
olanning  level  and  the  operational  control 


model  for  marag- 
compcsed  of  both 
suggests  that  the 
far-reaching  ef- 
.  Used  concur- 
smoother  transia- 
the  strategic 
level . 
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V.  SUMMARY.  CONCLUSIONS,  AND  RECOMM  ENDATIONS 

Presented  in  this  chapter  is  a  summary  of  the  thesis, 
aeneral  conclusions,  and  recommendations  for  further  study. 

A.  SUMMARY 

Various  met hcdoicgies  and  system  factors  relating  to 
software  cost  accounting  have  been  reviewed  in  an  attempt  to 
develop  a  cost  model  for  the  prediction  of  pure  maintenance 
costs.  The  distinction  between  development  costs  and 
maintenance  costs  is  considered  necessary  in  order  to  pre¬ 
sent  a  realistic  picture  of  the  annual  expenditures  within  a 
given  budget  constraint.  Without  a  refined  separation  of 
these  two  cost  entities,  budget  control  is  a  more  difficult 
task. 

Beginning  with  a  broad  background  of  what  maintenance  is 
and  is  not.  Chapter  One  uncovers  the  paradox  that  exists  in 
obtaining  a  consensus  for  a  common  working  definition  of 
maintenance.  Different  schools  of  thought  within  the  mili¬ 
tary  and  civilian  research  fields  have  produced  inconsisent 
results  when  citing  the  proportion  of  the  the  life-cycle 
costs  attributable  to  total  system  costs.  This  inconsis- 

in  part,  to  the  range  of  cost  types  (new 
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tency  may  be  due. 


development,  purs  aaintenance,  other  administrative  support 
activities,  etc.)  that  exist  during  the  aaintenance  phase. 
While  some  researchers  say  view  each  cost  type  individually, 
others  consider  the  aaintenance  costs  tc  be  an  aggregate  of 
all  expenditures  during  the  aaintenance  phase. 

In  Chapter  Two,  an  overview  of  the  extrinsic  and  intrin¬ 
sic  charactistics  of  a  software  system  which  create  the 
aaintenance  setting  is  provided.  It  is  apparent  froa  the 
detailed  discussion  of  the  more  salient  concepts  that  the 
maintenance  issue  is  not  only  coaplicated,  but  also  still 
somewhat  elusive.  While  these  concepts  have  been  useful  in 
explaining  systea  characteristics  and  predicting  future  be¬ 
havior,  they  fail  to  produce  a  means  for  direct  translation 
to  a  aonetary  value. 

although  no  cost  estimation  techniyue  adaptable  for  man¬ 
agement  use  has  teen  developed  solely  fcr  predicting  aainte¬ 
nance  costs,  application  of  software  cost  estimating  schemes 
originally  intended  to  evaluate  the  development  phase  have 
been  extended  tc  include  the  maintenance  phase.  Chapter 
Three  is  devoted  to  a  review  of  various  models  that  nave 
been  suggested  as  appropriate  for  addressing  the  maintenance 
cost  uncertainties.  The  models  two  avenues  for  approaching 
the  issue: 
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1)  a  total  system  concept  using  the  Ncrden-Bayleigh  curve, 
and 

2)  a  dynamic  system  philosophy  using  software  evolution 
analysis. 

Current  unavailability  of  a  basic  method  for  adequately 
determining  miantenance  expenditures  and  the  increasing  con¬ 
cern  of  DOD  for  the  exorbitant  funding  required  to  sustain 
software  system  operations  inspired  the  authors  to  develop  a 
flexible  management  model.  Chapter  Pour  elucidates  a  plan¬ 
ning  and  control  model  which  can  provide  project  managers 
with  additional  information  to  assist  in  budget  planning  and 
decision  making.  This  model  proffers  four  maintenance  stra¬ 
tegies  which  may  be  used  in  conjuction  with  calculated  maxi¬ 
mum  and  minimum  maintenance  level  support  boundaries  specif¬ 
ic  to  the  project  profile. 

B.  CONCLUSION 

While  an  abundance  of  research  in  software  economics  and 
software  engineering  exists,  very  little  has  been  done  that 
relates  to  the  maintenance  phase  of  the  software  life-cycle. 
As  a  result,  there  is  an  obvious  lack  of  raw  data  available 
to  analyze  the  proposed  model  for  validity  and  sensitivity. 

With  additional  research,  it  is  believed  that  the  model 
presented  in  this  thesis  will  provide  a  direct  means  to 
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evaluate  the  impact  of  current  and  future  management  prac¬ 


tices  on  the  life-cycle  costs  of  software  systems.  The  com- 
bined  use  of  the  simple  aacroestiaating  and  aicroestiaating 
techniques  allows  the  manager  to  look  at  the  maintenance 
problem  from  different  perspectives  while  increasing  the 
confidence  in  the  projected  maintenance  costs.  Additional¬ 
ly,  the  computation  of  minimum  and  maximum  levels  of  effort 
for  a  specific  project  leads  to  further  diminution  of  the 
problem  when  management  has  established  a  particular  mainte¬ 
nance  strategy. 


C.  RECOMMENDATIONS 

It  is  recommended  that  additional  work  within  DOD  be  un¬ 
dertaken  to  further  the  research  objectives  of  software 
maintenance  costs  and  that  this  work  include  the  following 


actions: 


1)  adoption  of  a  standard  definition  that  will  distinguish 
between  maintenance  costs  and  costs  incurred  in  the 
maintenance  life-cycle  phase; 


2)  institution  of  longitudinal  research  by  software  sup¬ 
port  facilities  to  collect  maintenance  data  to  be  used 
In  the  development  of  management  tools  with  improved 
caoability ; 


3)  investigaticn  of  the  usage  of  additional  prediction 
tools  to  obtain  a  more  complete  view  of  the‘ domain  of 
software  behavior  during  the  maintenance  phase;  and 


4)  analysis  of  empirical  data  to  prove  or  disprove  the 
following  statement:  The  more  over-budget  and  behind 

schedule  that  a  project  is  delivered,  the  higher  snouid 
be  the  prediction  of  errors  detected  in  the  maintenance 
phase . 


APPENDIX  k 


Contained  in  the  following  text  is  a  partial  sum¬ 
mary  of  a  aicroestiaating  technique  (Matrix  Estiaation 
Process)  obtained  froa  IBM  Federal  Systess  Division, 
Houston,  Texas. 

MATRIX  METHOD 

Definition:  The  Matrix  Method  is  a  systeaatic  procedure 
which  can  be  used  to  delineate  elements  of  a 
software  project  and  map  them  against  associat¬ 
ed  ccst  elements  to  arrive  at  a  project  esti¬ 
mate. 

Things  that  can  be  accoaplished : 

°  Lay  out  project  elements 
°  Stepwise  refine  the  elements 
0  Estimate  the  elements 

0  Subtotal  the  estimates  by  grouping 

the  elements 

0  Total  up  the  group  estimates 

0  Hefine  total  estimate 


U^e  of  the  Matrix  Method 

1.  Determine  functional  eleaents  of  project. 

2.  Quantify  Maintenance  needs  based  on  : 

Level  *  Function  Size  /  ((Productivity)  (Complexity) 
(Factor) 

3.  Consider  critical  skills,  operations  support,  and  man¬ 
agement  and  support. 

4.  Summarize  for  project. 

5.  Plot  with  Rayleigh  curve. 


Matrix  Estiafttjop  Proces, 


Lay  out  a  tails  of  functional  areas  of  code,  require- 
aents  areas,  test  areas,  or  functions  to  be  perforaed. 
Using  the  following  formulas,  calculate  the  level  re¬ 
quired  to  maintain  each  functional  area  or  function: 

Applications  Level  *  (FH  Size)/l(154)  (2)  (12)  (2)) 

FCOS  Level  =  (FW  Size)/ ((100)  (2)  (12)  (2)) 

SDL  Level  *  (K  Line  Size)/ ((15)  (2)) 

Computer  Resource  =  (FI ID  Hrs  Hk)  /  (28) 

GN6C  Verfi.  Level  *  (Number  Test  Cfc, sey-:.„  <»30)  (2)) 

SSH  Verif.  Level  *  (Number  Test  \  (5 )  (2) 

SM/PL  Verif.  Level  =  (Number  Test  /  { (20)  (2) 

Perf.  Verif.  Level  =  (Number  Test  Cmft*.?)/  ((5)  (2) 

All  Others: 

Level  *  (Development  or  Support  Level)/ (2) 

TSO  Level  =  Heguested  support  level  per  site 

Look  at  critical  skills  to  see  if  each  functional  area 

is  adequately  covered. 

Estimate  error  rate  and  rate  of  change  to  see  if  level 
should  be  altered. 


1 1b 


II 


amu 

ESTIMATE 

SUMMABI* 

Area 

Size 

Maint. 

Level 

CPN  S 
Support 

MSS 

Total 

AASD 

272918  PH 

42.0 

12.0 

10.0 

64.0 

CON/QA 

5.0 

— 

1.0 

6.0 

SEC.  SUPP 

11.0 

— 

— 

1  1.0 

AS  VO 

1247  TC 

83.5 

5.0 

15.5 

104.0 

140.5 

17.0 

26.5 

195.0 

*  Matrix  Summary  represents  decomposition  of  the  Space  Shut¬ 
tle  Program  intc  major  functional  areas. 
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iUlSi*  Estimate 

Summary 

* 

Code 

Maint . 

CPN  S 

Area 

Size 

Level 

Support 

MSS 

Total 

SM 

5a880 

6.7 

3.0 

1.3 

11.0 

vco 

57145 

5.2 

— 

.8 

6.0 

GNSC 

129918 

16.7 

4.0 

2.8 

23.5 

a.  A. 

— 

10.4 

5.0 

2.6 

18.0 

P.  A. 

30975 

3.0 

— 

.5 

3.5 

AASD 

2.0 

2.0 

MSS 

Totals 

272918 

42.0 

12.0 

10.0 

64.  0 

Note : 

This  table 

illustrates  an 

additional  decomposition 

of  a  aajcr  functional  area  into  subcomponents. 
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